[vlan multiplexing] handle kernel mechanism set with vlan parameter

[pperiyasamy]

update inject and connectioncontextkernel chain elements when kernel mechanism set with vlan parameter.

1. Move out parent interface out of nse container when last client is deleted.
2. do not configure ip/route/neighbor/mtu on the parent interface

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

[pperiyasamy]

/cc @JanScheurich

[JanScheurich]

Hi Peri, Let's have a call to discuss this. For standard kernel mechanisms, this looks good. But I'm not sure the unconditional creation of kernel sub-interfaces makes sense on a SmartVF where we expect the VLAN-tagged traffic to be handled by a DPDK application. I am also interested to see the NSE code, how the NSE decides whether or not to request VLAN multiplexing or rather a dedicated interface/VF per client connection. BR, Jan From: peri ***@***.***> Sent: Friday, 1 October, 2021 12:14 To: networkservicemesh/sdk-kernel ***@***.***> Cc: Jan Scheurich ***@***.***>; Mention ***@***.***> Subject: Re: [networkservicemesh/sdk-kernel] [vlan multiplexing] update inject client with vlan sub interface case (#346) /cc @JanScheurich<https://protect2.fireeye.com/v1/url?k=2874ea15-77efd338-2874aa8e-8692dc8284cb-5078ed3a0d9c45a2&q=1&e=64d0ec7d-7304-4810-b717-04c3428a0f8a&u=https%3A%2F%2Fgithub.com%2FJanScheurich> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://protect2.fireeye.com/v1/url?k=8f174723-d08c7e0e-8f1707b8-8692dc8284cb-d53f2299f5d9dc42&q=1&e=64d0ec7d-7304-4810-b717-04c3428a0f8a&u=https%3A%2F%2Fgithub.com%2Fnetworkservicemesh%2Fsdk-kernel%2Fpull%2F346%23issuecomment-932101255>, or unsubscribe<https://protect2.fireeye.com/v1/url?k=eb861013-b41d293e-eb865088-8692dc8284cb-131098be8f69f024&q=1&e=64d0ec7d-7304-4810-b717-04c3428a0f8a&u=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAHGNJJWYHTUTXWQB3TSZXTUEWCVXANCNFSM5FEKYIVQ>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://protect2.fireeye.com/v1/url?k=aa88c440-f513fd6d-aa8884db-8692dc8284cb-544665557916da28&q=1&e=64d0ec7d-7304-4810-b717-04c3428a0f8a&u=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26referrer%3Dutm_campaign%253Dnotification-email%2526utm_medium%253Demail%2526utm_source%253Dgithub>.

[pperiyasamy]

@edwarnicke @Bolodya1997 @denis-tingaikin I had a discussion with Jan on this and came up with following approach to avoid this unconditional creation of vlan sub interface.

1. Introduce ParentInterfaceName parameter in kernel mechanism (This needs a PR in api repo) which would be set from endpoint and InterfaceName parameter is used for vlan sub interface name.
2. when only parentInterfaceName is set and InterfaceName is set with a predefined string constant like "no-sub-interface", then forwarder just injects parent interface into endpoint pod and doesn't create any vlan sub interface on the container. This would cover DPDK case.
3. When Endpoint pod is started with single VF, then vlan tag server would be chosen and parent interface name is derived from service name (withParentInterface Option) itself.
4. There would an env config option provided in Endpoint container to choose DPDK scenario.

[edwarnicke]

@pperiyasamy Could you say a bit more... I don't quite follow the benefit in adding ParentInterfaceName... I am really really loath to introduce the 'subinterface' concept unnecessarily here... we are just describing the mechanism of encap, not how it represents in whatever system is providing it.

[pperiyasamy]

@edwarnicke The purpose of having parent interface name is to have proper naming convention like parent interface name derived from service name whereas sub interface derived from service name + connection id. yes, mechanim encaps parent interface name, interface name and vlan parameter.
The inject chain element (for kernel mechanism) is a place for realising it via VLAN sub interfaces. This PR just attempts to implement it on top of further sdk/api changes. do you have some other thoughts ?

[pperiyasamy]

@edwarnicke @JanScheurich It was a good discussion and thanks for your inputs. Based on the discussion, I have now updated relevant kernel chain elements to handle kernel mechanism set with vlan parameter. please take a look now.