From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pablo Neira Ayuso Subject: Re: [PATCH v4 net-next 7/9] net: ipv4: listified version of ip_rcv Date: Tue, 3 Jul 2018 12:50:35 +0200 Message-ID: <20180703105035.edifjogwotv3gzwy@salvia> References: <5bf84d99-8f77-54ee-7543-ada13a730361@solarflare.com> <68230d9e-e93c-ef91-4b54-e7aebedf1f84@solarflare.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: davem@davemloft.net, netdev@vger.kernel.org To: Edward Cree Return-path: Received: from mail.us.es ([193.147.175.20]:37910 "EHLO mail.us.es" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752381AbeGCKvD (ORCPT ); Tue, 3 Jul 2018 06:51:03 -0400 Received: from antivirus1-rhel7.int (unknown [192.168.2.11]) by mail.us.es (Postfix) with ESMTP id BC96FC3A16 for ; Tue, 3 Jul 2018 12:49:21 +0200 (CEST) Received: from antivirus1-rhel7.int (localhost [127.0.0.1]) by antivirus1-rhel7.int (Postfix) with ESMTP id 95DC1DA3E6 for ; Tue, 3 Jul 2018 12:49:21 +0200 (CEST) Content-Disposition: inline In-Reply-To: <68230d9e-e93c-ef91-4b54-e7aebedf1f84@solarflare.com> Sender: netdev-owner@vger.kernel.org List-ID: 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