On Mon, Jul 02, 2018 at 04:14:12PM +0100, Edward Cree wrote: > Also involved adding a way to run a netfilter hook over a list of packets. > Rather than attempting to make netfilter know about lists (which would be > a major project in itself) we just let it call the regular okfn (in this > case ip_rcv_finish()) for any packets it steals, and have it give us back > a list of packets it's synchronously accepted (which normally NF_HOOK > would automatically call okfn() on, but we want to be able to potentially > pass the list to a listified version of okfn().) > The netfilter hooks themselves are indirect calls that still happen per- > packet (see nf_hook_entry_hookfn()), but again, changing that can be left > for future work. > > There is potential for out-of-order receives if the netfilter hook ends up > synchronously stealing packets, as they will be processed before any > accepts earlier in the list. However, it was already possible for an > asynchronous accept to cause out-of-order receives, so presumably this is > considered OK.
I think we can simplify things if these chained packets don't follow the standard forwarding path, this would require to revisit many subsystems to handle these new chained packets - potentially a lot of work and likely breaking many things - and I would expect we (and other subsystems too) will not get very much benefits from these chained packets. In general I like this infrastructure, but I think we can get something simpler if we combine it with the flowtable idea, so chained packets follow the non-standard flowtable forwarding path as described in [1]. We could generalize and place the flowtable code in the core if needed, and make it not netfilter dependent if that's a problem. Thanks. [1] https://marc.info/?l=netfilter-devel&m=152898601419841&w=2
