On Tue, Oct 3, 2023 at 5:42 AM Jakub Kicinski <kuba@xxxxxxxxxx> wrote: > > On Mon, 02 Oct 2023 22:16:13 -0700 John Fastabend wrote: > > > This with the other piece we want from our side to allow running > > > verdict and sk_msg programs on sockets without having them in a > > > sockmap/sockhash it would seem like a better system to me. The > > > idea to drop the sockmap/sockhash is because we never remove progs > > > once they are added and we add them from sockops side. The filter > > > to socketes is almost always the port + metadata related to the > > > process or environment. This simplifies having to manage the > > > sockmap/sockhash and guess what size it should be. Sometimes we > > > overrun these maps and have to kill connections until we can > > > get more space. > > That's a step in the right direction for sure, but I still think that > Google's auto-lowat is the best approach. We just need a hook that > looks at incoming data and sets rcvlowat appropriately. That's it. > TCP looks at rcvlowat in a number of places to make protocol decisions, > not just the wake-up. Plus Google will no longer have to carry their > OOT patch.. David can correct me, but when he tried the SO_RCVLOWAT approach to solving this problem, he saw no improvements (and it might have actually been a regression in terms of behavior). I'd say that this sounds a bit suspicious and we have plans to get back to SO_RCVLOWAT and try to understand the behavior a bit better. I'll just say that the simpler the solution - the better. And if this rcvlowat hook gets us the ability to delay network notification to user-space until a full logical packet (where packet size is provided by BPF program without user space involvement) is assembled (up to some reasonable limits, of course), that would be great.
