All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Nicolas de Pesloüan" <nicolas.2p.debian@gmail.com>
To: Jiri Pirko <jpirko@redhat.com>
Cc: Andy Gospodarek <andy@greyhouse.net>,
	netdev@vger.kernel.org, davem@davemloft.net, fubar@us.ibm.com,
	eric.dumazet@gmail.com
Subject: Re: [patch net-next-2.6] bonding: remove skb_share_check in handle_frame
Date: Thu, 03 Mar 2011 09:37:58 +0100	[thread overview]
Message-ID: <4D6F5366.7000104@gmail.com> (raw)
In-Reply-To: <20110303061433.GA2835@psychotron.redhat.com>

Le 03/03/2011 07:14, Jiri Pirko a écrit :
> Wed, Mar 02, 2011 at 10:54:03PM CET, nicolas.2p.debian@gmail.com wrote:
[snip]
>> All those handlers that call netif_rx() or __netif_receive_skb()
>> sound horrible to me. Can you imagine the global overhead of the
>> above receive path?
>>
>> The reason why I suggested you introduce the goto another_round is
>> because most - if not all - stacking configurations could/should be
>> handled simply by returning the right skb from the rx_handler and let
>> __netif_receive_skb() loop. And by having the right orig_dev logic
>> inside __netif_receive_skb(), it could be possible to remove the
>> current vlan_on_bond_hook hack.
>
> Well that wouldn't solve the problem. if we just got anorther_round the
> packed would not be delivered to bond0.100 but only to bond0. That's
> also unwanted. Well, this think shouldn't have been added here in the
> first place :(

Yes, the packet would be delivered "exact match" to bond0, and this is what the bonding ARP handler 
expects, because it registered at this level, then deliver "exact match or NULL" to bond0.100, if 
appropriate, to whatever other protocol handlers.

There is a subtile difference between ptype_all and ptype_base delivery:

- The ptype_all handlers will receive the frame between two call to rx_handlers.
- The ptype_base handlers will receive the frame after all rx_handlers (and hard coded handlers like 
vlan) were called.

So a ptype_all handler might receive vlan tagged frame, if it register below the interface that 
untag the frame, while a ptype_base handler will always receive the untagged frame, because 
ptype_base delivery is done at the end of __netif_receive_skb().

I don't know whether it is desirable, but it used to be required for the bonding ARP monitor to work.

May be we should add some extra properties to protocol handler, so they can tell 
__netif_receive_skb() what they expect :

- a property to tell whether the protocol handler want the exact frame that cross the interface they 
registered on or the final frame, after all rx_handlers.
- a property to tell what they expect a the orig_dev value : the lowest interface known to 
__netif_receive_skb() (f_packet) or the interface one level below the interface they registered on 
(bonding ARP monitor).

Having those properties, I consider we would be in a position to remove most special hacks we 
currently have to handle particular stacking configuration.

	Nicolas.

      reply	other threads:[~2011-03-03  8:38 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-01  6:22 [patch net-next-2.6] bonding: remove skb_share_check in handle_frame Jiri Pirko
2011-03-01  9:29 ` Jiri Pirko
2011-03-01 15:12   ` Changli Gao
2011-03-01 20:11     ` Nicolas de Pesloüan
2011-03-02 16:13       ` Changli Gao
2011-03-02 21:05         ` Nicolas de Pesloüan
2011-03-01 20:38   ` Andy Gospodarek
2011-03-02 10:03     ` Jiri Pirko
2011-03-02 12:29       ` Jiri Pirko
2011-03-02 20:47       ` Nicolas de Pesloüan
2011-03-02 21:12         ` Jiri Pirko
2011-03-02 21:54           ` Nicolas de Pesloüan
2011-03-03  6:14             ` Jiri Pirko
2011-03-03  8:37               ` Nicolas de Pesloüan [this message]

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=4D6F5366.7000104@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=netdev@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.