Feature to perform pkt capturing on RX sides of interfaces

[byteocean]

The details are documented in the committed file capture_offloaded_rx_pkts.md

[guvenc]

@byteocean PR branch doesnt compile in the CI.

[PlagueCZ]

Okay, this is one big PR. I tried to cover all I saw, but that unfortunately means the comments are ranging from bugs to nitpicks, so please do not be discouraged, as a whole it looks really nicely done.

[PlagueCZ]

What will happen if you call for example start on vf1 and then separately start on vf2? If I read the code correctly, it will pass and now two interfaces will be captured?

And then what if you call start on vf1,vf2 and then start on vf3,vf2? This will fail and also will have to do a rollback of the vf3 rule right?

From the architecture, I understand why this "additive" behavior could be easier on the service, but on our last sync on this we talked about this being without any state, so I am trying to clarify how this works now.

(and also if we indeed do have a state, we would need a capture list command for the operator to know what is currently under capture)

[PlagueCZ]

How is isolation handled? Currently only IP-IP packets are allowed into dpservice, so this traffic will not enter it.
But what will happen once we start using IPv6? Or is that also planned to be in the tunnel so this is a non-issue even for the future?

[byteocean]

How is isolation handled? Currently only IP-IP packets are allowed into dpservice, so this traffic will not enter it. But what will happen once we start using IPv6? Or is that also planned to be in the tunnel so this is a non-issue even for the future?

Not extra isolation is needed. as we could just use native tcpdump on the pf ports, these extra packets will be captured together with other host packets. if a filter is applied to tcpdump to match udp ports, then only these extra packets will be written to file. IPv6 is also no problem, as they are part of the payload of UDP, and the extra bits for outer IPv6 and UDP can be stripped out by the tool in the readme.

[byteocean]

What will happen if you call for example start on vf1 and then separately start on vf2? If I read the code correctly, it will pass and now two interfaces will be captured?

And then what if you call start on vf1,vf2 and then start on vf3,vf2? This will fail and also will have to do a rollback of the vf3 rule right?

From the architecture, I understand why this "additive" behavior could be easier on the service, but on our last sync on this we talked about this being without any state, so I am trying to clarify how this works now.

(and also if we indeed do have a state, we would need a capture list command for the operator to know what is currently under capture)

the code is adjusted a bit to leave no state in between and operations on the interface set (union or subtraction) are not allowed. Additive behaviour was not part of the intention. To start capturing on a new set of interfaces, the stopping command has to be called first. Otherwise, the second start simply failed. this point is documented.