On 21/06/16 18:05, Alexander Duyck wrote: > On Tue, Jun 21, 2016 at 1:22 AM, David Miller <da...@davemloft.net> wrote: >> But anyways, the vastness of the key is why we want to keep "sockets" >> out of network cards, because proper support of "sockets" requires >> access to information the card simply does not and should not have. > Right. Really what I would like to see for most of these devices is a > 2 tuple filter where you specify the UDP port number, and the PF/VF ID > that the traffic is received on. But that doesn't make sense - the traffic is received on a physical network port, and it's the headers (i.e. flow) at that point that determine whether the traffic is encap or not. After all, those headers are all that can determine which PF or VF it's sent to; and if it's multicast and goes to more than one of them, it seems odd for one to treat it as encap and the other to treat it as normal UDP - one of them must be misinterpreting it (unless the UDP is going to a userspace tunnel endpoint, but I'm ignoring that complication for now). At a given physical point in the network, a given UDP flow either is or is not carrying encapsulated traffic, and if it tries to be both then things are certain to break, just as much as if two different applications try to use the same UDP flow for two different application protocols.
-Ed
