changes in direct memif implementation

[Mixaster995]

Signed-off-by: Mikhail Avramenko [email protected]

Related issues

networkservicemesh/deployments-k8s#2381
#373

Description

To fix problem with nse-composition i made and tested rework for direct memif.

[edwarnicke]

@Mixaster995 I'm a little curious why you are fixing this in mechanism/memif/client.go instead of in mechanism/memif/memifproxy ? It looks like you are simply replicating logic the memif proxy has for not recreating proxies for existing connections, only in memif/ rather than memif/proxy.

[Mixaster995]

Hello, @edwarnicke.
It is not related to memifproxy chain element.

Current direct memif logic working like this:

1. Create memif on nse
2. Create memif on client side of forwarder
3. On server side of forwarder check if client-side memif created delete it and not create server-side memif.
4. create memif on nsc
   every step happens on way back

With this fixes current logic is:

1. On way forward on server side of forwarder if left mechanism is memif, then add info to metadata
2. On way back on client side of forwarder check left(from metadata) and right mechanism to be memif (which is direct memif scenario)
3. In direct memif case not create memif on client side of forwarder and just save socket url to metada
4. On server side of forwarder not create memif and set mechanism socketurl from metada

Thus, we removing excessive memif creation on client side of forwarder, because it is not actually needed in direct memif scenario. And it is also eliminates leak reported in networkservicemesh/deployments-k8s#2381

[edwarnicke]

@Mixaster995 After much poking at it, this looks good. Could you flip to ready to review so we can merge it?