ethernetcontext and ipcontext client

[pperiyasamy]

The sdk-kernel repo contains ethernetcontext and ipcontext packages which support configuring mac address, ip and routes on network service client container, can we have client.go module so that same support is available for endpoint container. Most of the generic code can be moved under common.go.
There is also netns server code which runs subsequent server handler code under client container network namespace.
Should we also have such implementation for running ipcontext client for endpoint container ? or can that logic be part of ipcontext client module itself ?

[denis-tingaikin]

/cc @edwarnicke , @Bolodya1997

[Bolodya1997]

I guess creating ipcontext client is a good idea.

[edwarnicke]

@Bolodya1997 @pperiyasamy Might it make more sense to consider moving:

https://github.com/networkservicemesh/sdk-vpp/tree/main/pkg/networkservice/connectioncontextkernel

to sdk-kernel? Please note, doing so would also imply moving:

https://github.com/networkservicemesh/sdk-vpp/tree/main/pkg/tools/mechutils

@pperiyasamy @Bolodya1997 Thoughts?

[edwarnicke]

@pperiyasamy I also have PRs for:

Implement connectioncontextkernel/ethernetcontext/getmac
Implement connectioncontext/ethernetcontext/macaddress
Implement connectioncontextkernel/ethernetcontext/macaddress

That might be interesting to you as sources of suggestions... if we decide to move connectioncontextkernel to sdk-kernel, we probably want to consider implementing those here as well.

[pperiyasamy]

@edwarnicke yes, we can merge sdk-vpp's contextcontextkernel and sdk-kernel's ethernetcontext/ipcontext packages and have it under sdk-kernel/pkg/kernel/networkservice/connectioncontextkernel having both client and server handlers and make vpp and sriov forwarders consume it from this package. does it make sense ?

[pperiyasamy]

/cc @JanScheurich