On Thu, Dec 8, 2016 at 12:05 PM, Hannes Frederic Sowa <han...@stressinduktion.org> wrote: > Hello, > > On Thu, Dec 8, 2016, at 20:15, Tom Herbert wrote: >> On Thu, Dec 8, 2016 at 10:02 AM, Eric Dumazet <eric.duma...@gmail.com> >> wrote: >> > On Thu, 2016-12-08 at 09:49 -0800, Tom Herbert wrote: >> > >> >> Of course that would only help on systems where no one enable encaps, >> >> ie. looks good in the the simple benchmarks but in real life if just >> >> one socket enables encap everyone else takes the hit. Alternatively, >> >> maybe we could do early demux when we do the lookup in GRO to >> >> eliminate the extra lookup? >> > >> > Well, if you do the lookup in GRO, wont it be done for every incoming >> > MSS, instead of once per GRO packet ? >> >> We should be able to avoid that. We already do the lookup for every >> UDP packet going into GRO, would only need to take the refcnt once for >> the whole GRO packet. >> >> > >> > Anyway, the flooded UDP sockets out there are not normally connected >> >> We still should be able to use early demux in that case, just can't >> avoid the route lookup. I wonder if we might be able to cache a soft >> route maybe for the last local destination received to help the >> unconnected sockets case... >> >> In any case, I can take a look at of doing early demux from with UDP GRO. > > Early demux already breaks ip rules: we might set up a rule so an > incoming packet might depending on the rule not find an input route at > all and would be forwarded. Same problem might occur with VRF, when you > have multiple ip addresses in different "realms". > > That said, I don't see why we can't be more aggressive for GRO in the > unconnected case: we simply must make sure that the current namespace > holds the ip address, which is simply a hash lookup. After that we can > even accept packets for a wildcard bounded socket. > Or just depend on encapsulation sockets to bind to an address. That would eliminate most the ambiguity especially if it can be pushed into a device that is trying to parse encapsulation. We would need new interfaces to support that in HW, or use n-tuple filtering (which I still maintain is the only right way to do it).
Tom > Probably we should disable this logic as soon as soon as vrf and/or > rules are active to have correct semantics. > > Bye, > Hannes
