adapt to use connectioncontextkernel from sdk-kernel

[pperiyasamy]

Fixes #231

Signed-off-by: Periyasamy Palanisamy periyasamy.palanisamy@est.tech

[edwarnicke]

@pperiyasamy When I attempt to test this with downstream cmd-forwarder-vpp... its failing.

You might want to try it yourself by checking out this pr into cmd-forwarder-vpp/local/sdk-vpp and updating the cmd-forwarder-vpp/go.mod to poing sdk-vpp to it with a replace directive.

There is some helpful information on debugging here:
https://github.com/networkservicemesh/cmd-forwarder-vpp/blob/main/README.md

The other trick I use sometimes is to use:

				if clientMechanism != kernel.MECHANISM {
					continue
				}

here

and

						if endpointMechanism != kernel.MECHANISM {
							continue
						}

here

to restrict to only running across Kernel/Kernel cases (makes debugging much easier because you are only looking at the logs for that case).

[pperiyasamy]

@edwarnicke ok , thanks, This is a very handy tool.

I tried to run the test with this sdk-vpp version and looks test case started failing with error.

May 28 11:42:28.992 [INFO] Verifying Connection (time since start: 250.903106ms)
    suite_combinatronics_test.go:161:
                Error Trace:    suite_combinatronics_test.go:161
                Error:          Received unexpected error:
                                Link not found
                                unable to find interface "ns-a99926b1-2a3"
                                github.com/networkservicemesh/cmd-forwarder-vpp/internal/tests.checkKernelInterface
                                        /build/internal/tests/suite_kernel_test.go:204
                                github.com/networkservicemesh/cmd-forwarder-vpp/internal/tests.(*kernelVerifiableClient).VerifyConnection
                                        /build/internal/tests/suite_kernel_test.go:176
                                github.com/networkservicemesh/cmd-forwarder-vpp/internal/tests.(*ForwarderTestSuite).TestCombinations.func7.1.1
                                        /build/internal/tests/suite_combinatronics_test.go:161
                                testing.tRunner
                                        /go/src/testing/testing.go:1193
                                runtime.goexit
                                        /go/src/runtime/asm_amd64.s:1371
                Test:           TestForwarderTestSuite/TestCombinations/Ethernet/Kernel/Kernel
=== RUN   TestForwarderTestSuite/TestCombinations/Ip
=== RUN   TestForwarderTestSuite/TestCombinations/Ip/Kernel
=== RUN   TestForwarderTestSuite/TestCombinations/Ip/Kernel/Kernel
May 28 11:42:28.992 [INFO] Launching TestForwarderTestSuite/TestCombinations/Ip/Kernel/Kernel test server (time since start: 13.11µs)

The PR uses mechanism.GetInterfaceName(conn) (including sdk-kernel's connectioncontextkernel chain elements) instead of mechutils.ToInterfaceName(conn, isClient) to retrieve kernel interface name, but sdk-vpp's mechutils.ToAlias(...) is still intact. is it a problem for vpp ?
can we also make local sdk-vpp to use local sdk-kernel (tried to have cmd-forwarder-vpp/local/sdk-vpp/local/sdk-kernel, but somehow it didn't work) ? i thought of using mechutils.ToInterfaceName(conn, isClient) in all places and giving it a try.

[edwarnicke]

@pperiyasamy Ah... the isClient part is actually quite important...

[edwarnicke]

Basically... the mechanism.InterfaceName(conn) is computing the interface name based on the current connection id... but if you are a forwarder... you should be computing that interface based on the connection id of the NSE or NSC you are servicing, which will be either next or previous in the connection.Path.

So just calling mechanism.InterfaceName(conn) won't give you the right result in the context of a forwarder.