From: Cong Wang <amwang@redhat.com>
To: Neil Horman <nhorman@redhat.com>
Cc: linux-kernel@vger.kernel.org, Jiri Pirko <jpirko@redhat.com>,
netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Herbert Xu <herbert@gondor.hengli.com.au>,
bonding-devel@lists.sourceforge.net,
Jay Vosburgh <fubar@us.ibm.com>,
Stephen Hemminger <shemminger@vyatta.com>
Subject: Re: [v3 PATCH 1/2] bonding: sync netpoll code with bridge
Date: Wed, 15 Dec 2010 18:52:26 +0800 [thread overview]
Message-ID: <4D089DEA.2060803@redhat.com> (raw)
In-Reply-To: <4D008643.5040500@redhat.com>
于 2010年12月09日 15:33, Cong Wang 写道:
> On 12/08/10 21:57, Neil Horman wrote:
>> On Wed, Dec 08, 2010 at 02:52:08AM -0500, Amerigo Wang wrote:
>>> - bond_for_each_slave(bond, slave, i) {
>>> - if ((slave->dev->priv_flags& IFF_DISABLE_NETPOLL) ||
>>> - !slave->dev->netdev_ops->ndo_poll_controller)
>>> - ret = false;
>>> + np = kmalloc(sizeof(*np), GFP_KERNEL);
>>> + err = -ENOMEM;
>>> + if (!np)
>>> + goto out;
>>> +
>>> + np->dev = slave->dev;
>>> + err = __netpoll_setup(np);
>> Setting up our own netpoll instance on each slave worries me a bit. The
>> implication here is that, by doing so, some frames will get entirely processed
>> by the slave. Most notably arp frames. That means anything that gets queued up
>> to the arp_tx queue in __netpoll_rx will get processed during that poll event,
>> and responded to with the mac of the slave device, rather than with the mac of
>> the bond device, which isn't always what you want. I think if you go with this
>> route, you'll need to add code to netpoll_poll_dev, right before the call to
>> service_arp_queue, to check if IFF_SLAVE is set in priv_flags, and move the list
>> to the master device, or some such.
>
>
> Good point! Will fix i
Hi, Neil,
I think we should do that in bond_poll_controller() rather than netpoll_poll_dev(),
right? Since this is bond-specific. Does moving all arp_tx of slaves to their bond
address your concern?
Thanks!
next prev parent reply other threads:[~2010-12-15 10:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-08 7:52 [v3 PATCH 1/2] bonding: sync netpoll code with bridge Amerigo Wang
2010-12-08 7:52 ` [v3 PATCH 2/2] netpoll: remove IFF_IN_NETPOLL flag Amerigo Wang
2010-12-08 8:16 ` Changli Gao
2010-12-08 8:36 ` Cong Wang
2010-12-08 8:49 ` Changli Gao
2010-12-08 8:52 ` Cong Wang
2010-12-08 13:57 ` [v3 PATCH 1/2] bonding: sync netpoll code with bridge Neil Horman
2010-12-09 7:33 ` Cong Wang
2010-12-09 7:40 ` Cong Wang
2010-12-15 10:52 ` Cong Wang [this message]
2010-12-15 11:59 ` Neil Horman
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=4D089DEA.2060803@redhat.com \
--to=amwang@redhat.com \
--cc=bonding-devel@lists.sourceforge.net \
--cc=davem@davemloft.net \
--cc=ebiederm@xmission.com \
--cc=fubar@us.ibm.com \
--cc=herbert@gondor.hengli.com.au \
--cc=jpirko@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nhorman@redhat.com \
--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 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.