From: "Nicolas de Pesloüan" <nicolas.2p.debian@gmail.com>
To: Jiri Pirko <jpirko@redhat.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
David Miller <davem@davemloft.net>,
Stephen Hemminger <shemminger@vyatta.com>,
Jay Vosburgh <fubar@us.ibm.com>,
Patrick Mc Hardy <kaber@trash.net>,
Eric Dumazet <eric.dumazet@gmail.com>,
Andy Gospodarek <andy@greyhouse.net>
Subject: Re: Possible regression in __netif_receive_skb() between 2.6.38-rc7 and net-next-2.6
Date: Sun, 06 Mar 2011 14:08:33 +0100 [thread overview]
Message-ID: <4D738751.6050209@gmail.com> (raw)
In-Reply-To: <20110305220938.GK8573@psychotron.redhat.com>
Le 05/03/2011 23:09, Jiri Pirko a écrit :
> Sat, Mar 05, 2011 at 10:30:33PM CET, nicolas.2p.debian@gmail.com wrote:
>> Hi,
>>
>> Comparing __netif_receive_skb() between 2.6.38-rc7 and net-next-2.6,
>> I noticed an important difference: The ptype_base loop used to
>> deliver to orig_dev and this is not true anymore.
>
> I believe this is adressed by submitted patch " net: allow handlers to
> be processed for orig_dev"
I wonder whether we should address it that way (which is the former way to address it).
There are still a difference between ptype_all and ptype_base delivery:
- For ptype_all, we deliver to every device crossed while walking the rx_handler path (inside the
another_round loop). (And there is no way to force exact match delivery).
- For ptype_base, we deliver to the lowest device (orig_dev) and to the highest (skb->dev) and we
can ask for exact match delivery.
This sounds very inconsistent. The only difference between ptype_all and ptype_base is the fact that
ptype->type is NULL (wildcard) for the first and not NULL (a particular protocol) for the second.
I think we should:
1/ deliver to both ptype_all and ptype_base while walking the rx_handler path, but only exact match
(ptype->dev == skb->dev).
2/ deliver to both ptype_all and ptype_base at the end of __netif_receive_skb(), but only wildcard
match (ptype->dev == NULL), skipping this part if the last rx_handler returned RX_HANDLER_EXACT.
Nicolas.
>> Imagine the following simple setup:
>>
>> eth0 -> bond0
>>
>> - A packet handler registered on eth0, with ptype->type == NULL will
>> receive the packet, because it will be delivered in the ptype_all
>> loop, which is inside the another_round loop.
>> - The same packet handler, registered on eth0, but with ptype->type
>> != NULL won't receive the packet, because the ptype_base loop doesn't
>> deliver to orig_dev anymore.
>>
>> I think this can lead to a regression for user space: an application
>> using af_packet to listen to eth0 will receive the packet flow if the
>> registered protocol is NULL, but won't receive anything if the
>> registered protocol is not NULL.
>>
>> Can someone confirm?
>>
>> Nicolas.
>
next prev parent reply other threads:[~2011-03-06 13:08 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-05 21:30 Possible regression in __netif_receive_skb() between 2.6.38-rc7 and net-next-2.6 Nicolas de Pesloüan
2011-03-05 22:09 ` Jiri Pirko
2011-03-06 13:08 ` Nicolas de Pesloüan [this message]
2011-03-06 13:25 ` [PATCH net-next-2.6] net: harmonize the call to ptype_all and ptype_base handlers Nicolas de Pesloüan
2011-03-07 10:03 ` Jiri Pirko
2011-03-07 20:41 ` Nicolas de Pesloüan
2011-03-07 21:12 ` Jiri Pirko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D738751.6050209@gmail.com \
--to=nicolas.2p.debian@gmail.com \
--cc=andy@greyhouse.net \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=fubar@us.ibm.com \
--cc=jpirko@redhat.com \
--cc=kaber@trash.net \
--cc=netdev@vger.kernel.org \
--cc=shemminger@vyatta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).