From: Cong Wang <amwang@redhat.com>
To: David Miller <davem@davemloft.net>
Cc: fubar@us.ibm.com, nhorman@tuxdriver.com, netdev@vger.kernel.org,
mpm@selenic.com, bridge@lists.linux-foundation.org,
linux-kernel@vger.kernel.org, jmoyer@redhat.com,
gospo@redhat.com, bonding-devel@lists.sourceforge.net
Subject: Re: [Bridge] [RFC Patch 1/3] netpoll: add generic support for bridge and bonding devices
Date: Tue, 23 Mar 2010 12:47:39 +0800 [thread overview]
Message-ID: <4BA847EB.9040808@redhat.com> (raw)
In-Reply-To: <20100322.204939.146100390.davem@davemloft.net>
David Miller wrote:
> From: Cong Wang <amwang@redhat.com>
> Date: Tue, 23 Mar 2010 10:13:43 +0800
>
>> Matt Mackall wrote:
>>> Seems like a lot of interface for something to be used by only a
>>> couple
>>> core drivers. Hopefully Dave has an opinion here.
>>>
>> Yeah, I worry about this too, maybe we can group those methods
>> for netpoll together into another struct, and just put a pointer
>> here?
>
> This looks like it's tackled at the wrong layer, to be honest.
>
> Teaching all of these layers about eachother's states is
> going to end up being a nightmare in the end.
>
> All of this "where is the npinfo" business can be handled
> generically in net/core/dev.c I think, with none of these
> callbacks.
>
> For example, something like "if dev lacks ->npinfo, check
> it's master".
This is a good point! I haven't tried but certainly this is
worthy a try. Ideally those callbacks can be all removed,
but I don't know if this is true practically. ;)
I will try.
>
> Another thing, I wouldn't iterate over all devices, like I
> see in the bonding poll controller method. Just whichever
> one supports netpoll you see first, use it and exit
> immediately. Don't send it to every single port, I can't
> see how that might be desirable or useful.
Yeah, for bonding case, probably. But for bridge case, I think
we still need to check all, right?
Thanks!
WARNING: multiple messages have this Message-ID (diff)
From: Cong Wang <amwang@redhat.com>
To: David Miller <davem@davemloft.net>
Cc: mpm@selenic.com, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, bridge@lists.linux-foundation.org,
gospo@redhat.com, nhorman@tuxdriver.com,
shemminger@linux-foundation.org,
bonding-devel@lists.sourceforge.net, fubar@us.ibm.com,
jmoyer@redhat.com
Subject: Re: [RFC Patch 1/3] netpoll: add generic support for bridge and bonding devices
Date: Tue, 23 Mar 2010 12:47:39 +0800 [thread overview]
Message-ID: <4BA847EB.9040808@redhat.com> (raw)
In-Reply-To: <20100322.204939.146100390.davem@davemloft.net>
David Miller wrote:
> From: Cong Wang <amwang@redhat.com>
> Date: Tue, 23 Mar 2010 10:13:43 +0800
>
>> Matt Mackall wrote:
>>> Seems like a lot of interface for something to be used by only a
>>> couple
>>> core drivers. Hopefully Dave has an opinion here.
>>>
>> Yeah, I worry about this too, maybe we can group those methods
>> for netpoll together into another struct, and just put a pointer
>> here?
>
> This looks like it's tackled at the wrong layer, to be honest.
>
> Teaching all of these layers about eachother's states is
> going to end up being a nightmare in the end.
>
> All of this "where is the npinfo" business can be handled
> generically in net/core/dev.c I think, with none of these
> callbacks.
>
> For example, something like "if dev lacks ->npinfo, check
> it's master".
This is a good point! I haven't tried but certainly this is
worthy a try. Ideally those callbacks can be all removed,
but I don't know if this is true practically. ;)
I will try.
>
> Another thing, I wouldn't iterate over all devices, like I
> see in the bonding poll controller method. Just whichever
> one supports netpoll you see first, use it and exit
> immediately. Don't send it to every single port, I can't
> see how that might be desirable or useful.
Yeah, for bonding case, probably. But for bridge case, I think
we still need to check all, right?
Thanks!
next prev parent reply other threads:[~2010-03-23 4:47 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-22 8:17 [Bridge] [RFC Patch 1/3] netpoll: add generic support for bridge and bonding devices Amerigo Wang
2010-03-22 8:17 ` Amerigo Wang
2010-03-22 8:17 ` [Bridge] [RFC Patch 2/3] bridge: make bridge support netpoll Amerigo Wang
2010-03-22 8:17 ` Amerigo Wang
2010-03-22 22:35 ` [Bridge] " Matt Mackall
2010-03-22 22:35 ` Matt Mackall
2010-03-23 2:03 ` [Bridge] " Cong Wang
2010-03-23 2:03 ` Cong Wang
2010-03-23 4:27 ` [Bridge] " Matt Mackall
2010-03-23 4:27 ` Matt Mackall
2010-03-23 4:39 ` [Bridge] " Cong Wang
2010-03-23 4:39 ` Cong Wang
2010-03-23 4:51 ` [Bridge] " Matt Mackall
2010-03-23 4:51 ` Matt Mackall
2010-03-23 4:59 ` [Bridge] " David Miller
2010-03-23 4:59 ` David Miller
2010-03-23 5:00 ` [Bridge] " Cong Wang
2010-03-23 5:00 ` Cong Wang
2010-03-23 4:57 ` [Bridge] " David Miller
2010-03-23 4:57 ` David Miller
2010-03-23 5:06 ` [Bridge] " Cong Wang
2010-03-23 5:06 ` Cong Wang
2010-03-22 8:17 ` [Bridge] [RFC Patch 3/3] bonding: make bonding " Amerigo Wang
2010-03-22 8:17 ` Amerigo Wang
2010-03-22 22:38 ` [Bridge] " Matt Mackall
2010-03-22 22:38 ` Matt Mackall
2010-03-22 23:36 ` [Bridge] " Jay Vosburgh
2010-03-22 23:36 ` Jay Vosburgh
2010-03-23 2:01 ` [Bridge] " Cong Wang
2010-03-23 2:01 ` Cong Wang
2010-03-23 0:56 ` [Bridge] " Andy Gospodarek
2010-03-23 0:56 ` Andy Gospodarek
2010-03-23 1:49 ` [Bridge] " Cong Wang
2010-03-23 1:49 ` Cong Wang
2010-03-22 22:31 ` [Bridge] [RFC Patch 1/3] netpoll: add generic support for bridge and bonding devices Matt Mackall
2010-03-22 22:31 ` Matt Mackall
2010-03-23 2:13 ` [Bridge] " Cong Wang
2010-03-23 2:13 ` Cong Wang
2010-03-23 3:49 ` [Bridge] " David Miller
2010-03-23 3:49 ` David Miller
2010-03-23 4:47 ` Cong Wang [this message]
2010-03-23 4:47 ` Cong Wang
2010-03-23 4:58 ` [Bridge] " David Miller
2010-03-23 4:58 ` David Miller
2010-03-23 5:15 ` [Bridge] " Cong Wang
2010-03-23 5:15 ` Cong Wang
2010-03-23 12:11 ` [Bridge] " Jeff Moyer
2010-03-23 12:11 ` Jeff Moyer
2010-03-24 2:29 ` [Bridge] " Cong Wang
2010-03-24 2:29 ` Cong Wang
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=4BA847EB.9040808@redhat.com \
--to=amwang@redhat.com \
--cc=bonding-devel@lists.sourceforge.net \
--cc=bridge@lists.linux-foundation.org \
--cc=davem@davemloft.net \
--cc=fubar@us.ibm.com \
--cc=gospo@redhat.com \
--cc=jmoyer@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mpm@selenic.com \
--cc=netdev@vger.kernel.org \
--cc=nhorman@tuxdriver.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.