[vlan multiplexing] share single sriov token across connections

[pperiyasamy]

This would set kernel mechanism with shared sriov token id and unique VLAN id for every client connection when NSE is started with single VF resource.

Signed-off-by: Periyasamy Palanisamy [email protected]

[pperiyasamy]

/cc @JanScheurich

[edwarnicke]

@pperiyasamy What is we wanted a different multiplexing at this level than vlanid in the future? Basically, what I'm asking is: wouldn't this make more sense as a separate chain element using something like https://github.com/networkservicemesh/sdk/tree/main/pkg/networkservice/common/switchcase ?

[pperiyasamy]

@edwarnicke sure! I can move set vlan id part into another switch case chain element. does this multiplexing type come from mechanism preference ?

[Bolodya1997]

@edwarnicke sure! I can move set vlan id part into another switch case chain element. does this multiplexing type come from mechanism preference ?

I suppose that may decide what multiplexing type to use when we build the chain. But we probably want to be able create different chains without incorporating VLAN logic to token server.

... -> token server -> vlan server -> ...
... -> token server -> something else server -> ...

[JanScheurich]

If I recall the discussion we had a few weeks back correctly, Ed suggested that the possibility to multiplex many client connections over a single NSE pod interface should be generic and not limited to the case of SRIOV/Smart VFs (where it makes most sense, obviously). There should not be any dependency on the token server chain element.

[pperiyasamy]

@JanScheurich @edwarnicke had an offline discussion with @Bolodya1997 on this further and we felt kernel mechanism server is the best place to add vlan tag on the mechanism parameter, here is the PR for it. Please have a look.