* Re: [RFC Patch 1/3] netpoll: add generic support for bridge and bonding devices
From: Cong Wang @ 2010-03-23 2:13 UTC (permalink / raw)
To: Matt Mackall
Cc: linux-kernel, netdev, bridge, Andy Gospodarek, Neil Horman,
Stephen Hemminger, bonding-devel, Jay Vosburgh, David Miller,
Jeff Moyer
In-Reply-To: <1269297081.3552.19.camel@calx>
Matt Mackall wrote:
> On Mon, 2010-03-22 at 04:17 -0400, Amerigo Wang wrote:
>> This whole patchset is for adding netpoll support to bridge and bonding
>> devices. I already tested it for bridge, bonding, bridge over bonding,
>> and bonding over bridge. It looks fine now.
>
> Ages ago, Jeff Moyer took a run at this, added him to the cc: on the off
> chance he still cares.
>
>> Please comment.
>>
>>
>> To make bridge and bonding support netpoll, we need to adjust
>> some netpoll generic code. This patch does the following things:
>>
>> 1) introduce two new priv_flags for struct net_device:
>> IFF_IN_NETPOLL which identifies we are processing a netpoll;
>> IFF_DISABLE_NETPOLL is used to disable netpoll support for a device
>> at run-time;
>
> This one is a little worrisome. I've tried to keep the netpoll code
> restricted to as tight an area as possible. Adding new flags like these
> that random drivers might try to fiddle with seems like a good way for a
> driver writer to get in trouble. Also flag space is filling up.
Somewhat, but currently I don't have other way to replace this.
Any suggestions?
>
>> 2) introduce three new methods for netdev_ops:
>> ->ndo_netpoll_setup() is used to setup netpoll for a device;
>> ->ndo_netpoll_xmit() is used to transmit netpoll requests;
>> ->ndo_netpoll_cleanup() is used to clean up netpoll when a device is
>> removed.
>
> 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?
Thanks!
^ permalink raw reply
* Re: [RFC Patch 3/3] bonding: make bonding support netpoll
From: Cong Wang @ 2010-03-23 2:01 UTC (permalink / raw)
To: Jay Vosburgh
Cc: Matt Mackall, linux-kernel, netdev, bridge, Andy Gospodarek,
Neil Horman, Stephen Hemminger, bonding-devel, David Miller
In-Reply-To: <12061.1269301015@death.nxdomain.ibm.com>
Jay Vosburgh wrote:
> Matt Mackall <mpm@selenic.com> wrote:
>
>> On Mon, 2010-03-22 at 04:17 -0400, Amerigo Wang wrote:
>>> Based on Andy's work, but I modify a lot.
>>>
>>> Similar to the patch for bridge, this patch does:
>>>
>>> 1) implement the 4 methods to support netpoll for bonding;
>>>
>>> 2) modify netpoll during forwarding packets in bonding;
>>>
>>> 3) disable netpoll support of bridge when a netpoll-unabled device
>>> is added to bonding;
>>>
>>> 4) enable netpoll support when all underlying devices support netpoll.
>> Again, not sure if this is the right policy. Seems to me that on a
>> bonding device we should simply pick an interface to send netpoll
>> messages on, without reference to balancing, etc. Thus, if any of the
>> bonded devices supports polling, it should work.
>
> For some of the modes, the above is pretty straighforward.
> Others, 802.3ad and balance-alb, are a bit more complicated.
>
> The risk is that the network peers and switches may see the same
> MAC address on multiple ports, or different MAC addresses for the same
> IP address.
>
> To implement the above suggestion, I think a "current netpoll
> slave" would have to be tracked, and kept up to date (as slaves become
> active or inactive, etc). Reusing the existing "current active slave"
> won't work for the case that the active slave is not netpoll-capable,
> but a different slave is; also, not all modes use the current active
> slave.
>
> In 802.3ad, the "current netpoll slave" selector will have to
> poke into the aggregator status to choose the netpoll slave. It's not a
> simple matter of picking one and then sticking with it forever; if the
> aggregator containing the netpoll slave is deactivated, then peers may
> not receive the traffic, etc.
>
> In the active-backup mode, only the active slave can send or
> receive, so if it's not netpoll capable, but a backup slave is, you're
> still out of luck (unless netpoll awareness is added to the "best slave"
> selection logic, and even then it'd have to be a secondary criteria).
> Or, the inactive slave can be transmitted on, but if the same MAC comes
> out of the active and a backup slave, it can confuse switches.
>
> In one mode (balance-alb), slaves keep their own MAC addresses,
> and are matched with peers. Bypassing the balance algorithm could again
> confuse peers or switches, who could see two MAC addresses for the same
> IP address, if netpoll traffic goes out a different slave than the
> balance algorithm picks for the same destination.
>
> I think, then, the question becomes: is this extra complexity
> worth it to cover the cases of netpoll over bonding wherein one or more
> slaves don't support netpoll?
>
I see, thanks for your explanation, I overlooked the bonding case.
The current implementation will totally disable netpoll when at least one
slave doesn't support netpoll, so it looks like a safe choice. ;)
> How many network drivers don't support netpoll nowadays?
>
Only about 20% of network drivers support netpoll, a quick grep of 'ndo_poll_controller'
can show that.
Thanks a lot!
^ permalink raw reply
* Re: [RFC Patch 2/3] bridge: make bridge support netpoll
From: Cong Wang @ 2010-03-23 2:03 UTC (permalink / raw)
To: Matt Mackall
Cc: linux-kernel, netdev, bridge, Andy Gospodarek, Neil Horman,
Stephen Hemminger, bonding-devel, Jay Vosburgh, David Miller
In-Reply-To: <1269297307.3552.23.camel@calx>
Matt Mackall wrote:
> On Mon, 2010-03-22 at 04:17 -0400, Amerigo Wang wrote:
>> Based on the previous patch, make bridge support netpoll by:
>>
>> 1) implement the 4 methods to support netpoll for bridge;
>>
>> 2) modify netpoll during forwarding packets in bridge;
>>
>> 3) disable netpoll support of bridge when a netpoll-unabled device
>> is added to bridge;
>
> Not sure if this is the right thing to do. Shouldn't we simply enable
> polling on all devices that support it and warn about the others (aka
> best effort)?
>
I don't think it's a good idea, because we check if a device
supports netpoll by checking if it has ndo_poll_controller method.
Thanks.
^ permalink raw reply
* Re: [Uclinux-dist-devel] [PATCH] can: bfin_can: switch to common Blackfin can header
From: David Miller @ 2010-03-23 1:57 UTC (permalink / raw)
To: vapier.adi
Cc: socketcan-core, netdev, uclinux-dist-devel, oliver.hartkopp,
urs.thuermann
In-Reply-To: <8bd0f97a1003221850p50fd9d1fq55a56265c19ca528@mail.gmail.com>
From: Mike Frysinger <vapier.adi@gmail.com>
Date: Mon, 22 Mar 2010 21:50:56 -0400
> On Mon, Mar 22, 2010 at 21:48, David Miller wrote:
>> From: Mike Frysinger
>>> how about we skip to the end where we agree i'm wrong, you're right,
>>> and you just merge the patch that i already resent ...
>>
>> Sure, if you wish to make it clear that you have zero
>> interest in understanding the substance of this issue.
>
> whatever makes you happy. you dont appear to have much interest in my
> explanations.
Your explanation is that "resubmit" doesn't really mean "resubmit"
even when mutliple people request it of you.
And you just think that "just do this" is a simple request when
it's thrown at a maintainer like me who has to deal with sometimes
hundreds of patch submissions per day.
It's _not_.
You do it if you don't believe me. I bet you'll have a different view
of the world and a different set of expectations after that.
^ permalink raw reply
* Re: kaweth: New USB ID 07c9:b010 Allied Telesyn AT-USB10
From: David Miller @ 2010-03-23 1:53 UTC (permalink / raw)
To: andi; +Cc: netdev
Your patch was corrupted by your email client, in particular
tab characters were transformed into spaces.
Please turn all text formatting options off in your email client
and resubmit your patch in a form that will actually apply.
If you are unsure, send yourself the patch and try to apply cleanly
the patch in the email you receive. You will save us a lot of time if
you make sure what you send is usable for us so please take the time
to do this right.
Thanks.
^ permalink raw reply
* Re: [Uclinux-dist-devel] [PATCH] can: bfin_can: switch to common Blackfin can header
From: Mike Frysinger @ 2010-03-23 1:50 UTC (permalink / raw)
To: David Miller
Cc: socketcan-core, netdev, uclinux-dist-devel, oliver.hartkopp,
urs.thuermann
In-Reply-To: <20100322.184830.93460099.davem@davemloft.net>
On Mon, Mar 22, 2010 at 21:48, David Miller wrote:
> From: Mike Frysinger
>> how about we skip to the end where we agree i'm wrong, you're right,
>> and you just merge the patch that i already resent ...
>
> Sure, if you wish to make it clear that you have zero
> interest in understanding the substance of this issue.
whatever makes you happy. you dont appear to have much interest in my
explanations.
-mike
^ permalink raw reply
* Re: [RFC Patch 3/3] bonding: make bonding support netpoll
From: Cong Wang @ 2010-03-23 1:49 UTC (permalink / raw)
To: Andy Gospodarek
Cc: linux-kernel, netdev, bridge, Andy Gospodarek, Neil Horman,
Stephen Hemminger, bonding-devel, Jay Vosburgh, David Miller
In-Reply-To: <20100323005639.GH2108@gospo.rdu.redhat.com>
Andy Gospodarek wrote:
> On Mon, Mar 22, 2010 at 04:17:40AM -0400, Amerigo Wang wrote:
>> Based on Andy's work, but I modify a lot.
>>
>> Similar to the patch for bridge, this patch does:
>>
>> 1) implement the 4 methods to support netpoll for bonding;
>>
>> 2) modify netpoll during forwarding packets in bonding;
>>
>> 3) disable netpoll support of bridge when a netpoll-unabled device
>> is added to bonding;
>>
>> 4) enable netpoll support when all underlying devices support netpoll.
>>
>> Cc: Andy Gospodarek <gospo@redhat.com>
>> Cc: Neil Horman <nhorman@tuxdriver.com>
>> Cc: Jay Vosburgh <fubar@us.ibm.com>
>> Cc: David Miller <davem@davemloft.net>
>> Signed-off-by: WANG Cong <amwang@redhat.com>
>>
>
> How much testing was done on this?
>
> One of the potential problems with this code is how gracefully the
> system can handle tear-down of interfaces or removal of the bonding
> module when netconsole is active. Was that tested heavily?
>
For this case you mention, I did test it, but what I did is mainly basic
functionality testing, including bonding over bridge and bridge over bonding.
Thanks!
^ permalink raw reply
* Re: [PATCH] can: bfin_can: switch to common Blackfin can header
From: David Miller @ 2010-03-23 1:48 UTC (permalink / raw)
To: vapier.adi-Re5JQEeQqe8AvxtiuMwx3w
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
urs.thuermann-l29pVbxQd1IUtdQbppsyvg,
oliver.hartkopp-l29pVbxQd1IUtdQbppsyvg,
uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b
In-Reply-To: <8bd0f97a1003221842k4e44bfccmfc7858b9c793b44f-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
From: Mike Frysinger <vapier.adi-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Mon, 22 Mar 2010 21:42:43 -0400
> how about we skip to the end where we agree i'm wrong, you're right,
> and you just merge the patch that i already resent ...
Sure, if you wish to make it clear that you have zero
interest in understanding the substance of this issue.
What part of:
You only have to deal with me, and I have to deal with
hundreds of developers, so make my life as simple as possible
ok?
do you not understand?
Multiply every grievance you throw my way by however many other
patches, bug reports, and issues I deal with on a given day.
I think this is the part you don't get.
^ permalink raw reply
* Re: [Patch v2] netpoll: warn when there are spaces in parameters
From: Cong Wang @ 2010-03-23 1:44 UTC (permalink / raw)
To: Matt Mackall; +Cc: linux-kernel, netdev, elendil, David Miller
In-Reply-To: <1269296535.3552.10.camel@calx>
Matt Mackall wrote:
> On Mon, 2010-03-22 at 04:59 -0400, Amerigo Wang wrote:
>> + printk(KERN_INFO "%s: warning: whitespace"
>> + "is not allowed\n", np->name);
>
> Is it a warning or is it info? If it's a warning, then we probably need
> to add "netpoll" or whatever to the message so that people who've got a
> warning-level threshold will know what it's about.
>
If you mean KERN_INFO, yeah, I want to keep it in the same level
as other messages around.
Also, I already put "np->name" which will be "netconsole" when
we use netconsole.
Thanks.
^ permalink raw reply
* Re: [Uclinux-dist-devel] [PATCH] can: bfin_can: switch to common Blackfin can header
From: Mike Frysinger @ 2010-03-23 1:42 UTC (permalink / raw)
To: David Miller
Cc: socketcan-core, netdev, uclinux-dist-devel, oliver.hartkopp,
urs.thuermann
In-Reply-To: <20100322.163637.73665927.davem@davemloft.net>
On Mon, Mar 22, 2010 at 19:36, David Miller wrote:
> From: Mike Frysinger <vapier.adi@gmail.com>
>> On Mon, Mar 22, 2010 at 13:17, David Miller wrote:
>>> From: Mike Frysinger <vapier.adi@gmail.com>
>>> Do you still feel this way after people other than me also asked you
>>> to do the same exact thing for me? Do you think they are making
>>> arbitrary requests as well?
>>
>> the only other person to say anything did not say "you now need to
>> resend your patch". it was "please wait until Linus has pulled things
>> and then Dave has pulled things". which was not relevant at the point
>> it was sent.
>
> Wolfgang told you to "just resubmit the patch", just like I asked you
> to, when you said "the code is there just apply the old one."
i see no e-mail from Wolfgang. did he miss some CC's ? or do you mean Oliver ?
how about we skip to the end where we agree i'm wrong, you're right,
and you just merge the patch that i already resent ...
-mike
^ permalink raw reply
* [BUG] XFRM is not updating RTAX_ADVMSS metric
From: Eduardo Panisset @ 2010-03-23 1:35 UTC (permalink / raw)
To: netdev
Hi All,
I have been testing DSMIPv6 code which uses all kind of advanced
features of XFRM framework and I believe I have found a bug related to
update RTAX_ADVMSS route metric.
The XFRM code on net/xfrm/xfrm_policy.c by its functions
xfrm_init_pmtu and xfrm_bundle_ok updates RTAX_MTU route caching
metric however I believe it must update RTAX_ADVMSS as this later is
used by tcp connect function for adverting the MSS value on SYN
messages.
As MSS is not being updated by XFRM the TCP SYN messages (e.g.
originated from a internet browser) is erroneously informing its MSS
(without taking into account the overhead added to IP packet size by
XFRM transformations). One result of that is the browser gets
"frozen" after starts a TCP connection because TCP messages sent by
TCP server will never get to it (TCP server is sending too large
segments to browser).
Below I describe the changes I have done (on xfrm_init_pmtu and
xfrm_bundle_ok) and that seem to fix this problem:
xfrm_init_pmtu:
.
.
.
dst->metrics[RTAX_MTU-1] = pmtu; // original code, below my changes
if (dst->xfrm->props.mode == XFRM_MODE_TUNNEL)
switch (dst->xfrm->props.family)
{
case AF_INET:
dst->metrics[RTAX_ADVMSS-1] = max_t(unsigned int,
pmtu - sizeof(struct iphdr) - sizeof(struct tcphdr), 256);
break;
case AF_INET6:
dst->metrics[RTAX_ADVMSS-1] = max_t(unsigned int,
pmtu - sizeof(struct ipv6hdr) - sizeof(struct tcphdr),
dev_net(dst->dev)->ipv6.
sysctl.ip6_rt_min_advmss);
break;
}
xfrm_bundle_ok:
.
.
.
dst->metrics[RTAX_MTU-1] = mtu; // original code, below my changes
if (dst->xfrm->props.mode == XFRM_MODE_TUNNEL)
switch (dst->xfrm->props.family)
{
case AF_INET:
dst->metrics[RTAX_ADVMSS-1] = max_t(unsigned
int, mtu - sizeof(struct iphdr) - sizeof(struct tcphdr), 256);
break;
case AF_INET6:
dst->metrics[RTAX_ADVMSS-1] = max_t(unsigned
int, mtu - sizeof(struct ipv6hdr) - sizeof(struct tcphdr),
dev_net(dst->dev)->ipv6.sysctl.ip6_rt_min_advmss);
break;
}
Regards,
Eduardo Panisset.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] ipoib: remove addrlen check for mc addresses
From: David Miller @ 2010-03-23 1:34 UTC (permalink / raw)
To: jpirko-H+wXaHxf7aLQT0dZR+AlfA
Cc: jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/,
netdev-u79uwXL29TY76Z2rM5mHXA, ogerlitz-smomgflXvOZWk0Htik3J/w,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, monis-smomgflXvOZWk0Htik3J/w
In-Reply-To: <20100322172613.GA2884-YzwxZg+R7et1/kRsl7OVgNvLeJWuRmrY@public.gmane.org>
From: Jiri Pirko <jpirko-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Date: Mon, 22 Mar 2010 18:26:14 +0100
> Mon, Mar 22, 2010 at 05:59:16PM CET, jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org wrote:
>>On Mon, Mar 22, 2010 at 02:21:39PM +0100, Jiri Pirko wrote:
>>> Finally this bit can be removed. Currently, after the bonding driver is
>>> changed/fixed (32a806c194ea112cfab00f558482dd97bee5e44e net-next-2.6),
>>> that's not possible for an addr with different length than dev->addr_len
>>> to be present in list. Removing this check as in new mc_list there will be
>>> no addrlen in the record.
>>
>>Maybe just make this check a WARN_ON?
>
> As I said, addrlen will no longer be in record (because it would have no
> meaning since length ot the addr is always dev->addr_len)
>
>>Can userspace create a mc_list
>>entry with the wrong size via netlink?
>
> Nope - this is not possible. dev->addr_len is used.
I've applied your patch, thanks Jiri.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Patch] netconsole: do not depend on experimental
From: David Miller @ 2010-03-23 1:33 UTC (permalink / raw)
To: amwang; +Cc: linux-kernel, netdev
In-Reply-To: <20100322100305.5518.29500.sendpatchset@localhost.localdomain>
From: Amerigo Wang <amwang@redhat.com>
Date: Mon, 22 Mar 2010 05:59:23 -0400
>
> Nowadays, most distributions enable netconsole by default,
> including RHEL, Fedora, Debian, Arch, Opensuse. And
> we don't have any bug reports about it. So I think there
> is no need to mark it as experimental any more.
>
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: WANG Cong <amwang@redhat.com>
Applied.
^ permalink raw reply
* Re: [patch] ewrk3: range checking problem
From: David Miller @ 2010-03-23 1:33 UTC (permalink / raw)
To: error27
Cc: netdev, shemminger, kaber, jpirko, adobriyan, linux-kernel,
kernel-janitors
In-Reply-To: <20100322120728.GD21571@bicker>
From: Dan Carpenter <error27@gmail.com>
Date: Mon, 22 Mar 2010 15:07:28 +0300
> The range checking here is wrong. It should be HASH_TABLE_LEN which
> is 512.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
Applied.
^ permalink raw reply
* Re: [patch] stmmac: use resource_size()
From: David Miller @ 2010-03-23 1:33 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: error27, netdev, joe, linux-kernel, kernel-janitors
In-Reply-To: <4BA78977.6020801@st.com>
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Date: Mon, 22 Mar 2010 16:15:03 +0100
> Hi Dan
> Thanks, the patch can also applied against the net-next driver and it's ok.
Applied, thanks everyone.
^ permalink raw reply
* Re: [patch] korina: use resource_size()
From: David Miller @ 2010-03-23 1:33 UTC (permalink / raw)
To: error27; +Cc: netdev, kernel-janitors, n0-1, jpirko, shemminger, joe
In-Reply-To: <20100322121145.GK21571@bicker>
From: Dan Carpenter <error27@gmail.com>
Date: Mon, 22 Mar 2010 15:11:45 +0300
> This size calculation is wrong. It should be end - start + 1.
> Use resource_size() to calculate it correctly.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 3/3] igb: add support for Intel I350 Gigabit Network Connection
From: David Miller @ 2010-03-23 1:30 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, alexander.h.duyck, james.r.hearn
In-Reply-To: <20100323000804.19939.27632.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 22 Mar 2010 17:08:06 -0700
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> This patch adds support for the the I350 Gigabit network connection which
> is the follow-on part to the 82580.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> CC: James Hearn <james.r.hearn@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 2/3] igb: cleanup usage of virtualization registers
From: David Miller @ 2010-03-23 1:30 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, alexander.h.duyck
In-Reply-To: <20100323000744.19939.65933.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 22 Mar 2010 17:07:46 -0700
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> The igb driver was incorrectly attempting to write to registers that do not
> exist on 82580 hardware. This wasn't causing any issues that I can tell,
> but it is not recommended behavior either so I have changed this so we are
> determining which registers to write to based on mac type.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 1/3] igb: Do not overwrite mdicnfg register when accessing 82580 phy
From: David Miller @ 2010-03-23 1:30 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, alexander.h.duyck
In-Reply-To: <20100323000724.19939.17642.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 22 Mar 2010 17:07:26 -0700
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> This change removes the extra configuration we were doing on the mdicnfg
> register which should be set by EEPROM and which we should not need to
> write again afterwards. This code was a holdover from some earlier
> development work that was being done on a board with an incomplete EEPROM
> and is no longer needed now that the production EEPROMs are in place.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] igb: add IntMode module parameter
From: David Miller @ 2010-03-23 1:28 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, nicholasx.d.nunley
In-Reply-To: <20100323000519.19902.14802.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 22 Mar 2010 17:06:20 -0700
> From: Nick Nunley <nicholasx.d.nunley@intel.com>
>
> This patch adds the IntMode module parameter to igb. This
> allows user selection of interrupt mode (MSI-X, MSI, legacy)
> on driver load.
>
> Signed-off-by: Nicholas Nunley <nicholasx.d.nunley@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
And IGB is special and needs this for what reason?
If there are real interrupt issues then:
1) Diagnosing via verification of the problem can be simply performed
by asking the user to pass the generic kernel boot option to
globally disable MSI and friends.
2) Specifically disabling it for buggy parts belongs in the
driver or in the PCI quirk tables.
So from just about any angle, this module option makes no sense.
So I'm not applying it, sorry.
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2010-03-19
From: David Miller @ 2010-03-23 1:16 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100319204507.GF9552-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Fri, 19 Mar 2010 16:45:08 -0400
> Here is the first big dump of wireless bit for the 2.6.35 cycle...
>
> Included are the usual driver updates, etc. In particular, the Intel
> and Nokia guys have been busy as usual. :-)
Pulled, I'll push out to kernel.org after some build smoke
tests.
Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: rps: Fix build with CONFIG_SYSFS enabled
From: David Miller @ 2010-03-23 1:07 UTC (permalink / raw)
To: randy.dunlap; +Cc: therbert, netdev
In-Reply-To: <4BA7E5BF.1080805@oracle.com>
From: Randy Dunlap <randy.dunlap@oracle.com>
Date: Mon, 22 Mar 2010 14:48:47 -0700
> Dave, this patch and Eric's patch both build OK. Your choice...
Yep, I took Tom's, thanks for testing Randy.
^ permalink raw reply
* Re: rps: Fix build with CONFIG_SYSFS enabled
From: David Miller @ 2010-03-23 1:07 UTC (permalink / raw)
To: therbert; +Cc: netdev
In-Reply-To: <alpine.DEB.1.00.1003221355380.25849@pokey.mtv.corp.google.com>
From: Tom Herbert <therbert@google.com>
Date: Mon, 22 Mar 2010 13:57:56 -0700 (PDT)
> Fix build with CONFIG_SYSFS not enabled.
>
> Signed-off-by: Tom Herbert <therbert@google.com>
Applied, thanks everyone.
^ permalink raw reply
* Re: linux-next: Tree for March 22 (net-sysfs.c)
From: David Miller @ 2010-03-23 1:05 UTC (permalink / raw)
To: eric.dumazet
Cc: randy.dunlap, sfr, linux-next, linux-kernel, netdev, therbert
In-Reply-To: <1269290922.3043.9.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 22 Mar 2010 21:48:42 +0100
> [PATCH net-next-2.6] net: RPS depends on CONFIG_SYSFS
>
> Randy Dunlap found net/core/net-sysfs.c could not compile if
> CONFIG_SYSFS=n
>
> Defines CONFIG_RPS in net/Kconfig to let user disable RPS if wanted.
>
> Reported-by: Randy Dunlap <randy.dunlap@oracle.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
This is interesting but I'd like to be able to use some
of the RPS infrastructure unconditionally so I'm not ready
to apply something like this yet.
So I'll add Tom's fix for now, thanks Eric!
^ permalink raw reply
* Re: [RFC Patch 3/3] bonding: make bonding support netpoll
From: Andy Gospodarek @ 2010-03-23 0:56 UTC (permalink / raw)
To: Amerigo Wang
Cc: linux-kernel, netdev, bridge, Andy Gospodarek, Neil Horman,
Stephen Hemminger, bonding-devel, Jay Vosburgh, David Miller
In-Reply-To: <20100322082123.4967.77433.sendpatchset@localhost.localdomain>
On Mon, Mar 22, 2010 at 04:17:40AM -0400, Amerigo Wang wrote:
>
> Based on Andy's work, but I modify a lot.
>
> Similar to the patch for bridge, this patch does:
>
> 1) implement the 4 methods to support netpoll for bonding;
>
> 2) modify netpoll during forwarding packets in bonding;
>
> 3) disable netpoll support of bridge when a netpoll-unabled device
> is added to bonding;
>
> 4) enable netpoll support when all underlying devices support netpoll.
>
> Cc: Andy Gospodarek <gospo@redhat.com>
> Cc: Neil Horman <nhorman@tuxdriver.com>
> Cc: Jay Vosburgh <fubar@us.ibm.com>
> Cc: David Miller <davem@davemloft.net>
> Signed-off-by: WANG Cong <amwang@redhat.com>
>
How much testing was done on this?
One of the potential problems with this code is how gracefully the
system can handle tear-down of interfaces or removal of the bonding
module when netconsole is active. Was that tested heavily?
>
> ---
> Index: linux-2.6/drivers/net/bonding/bond_main.c
> ===================================================================
> --- linux-2.6.orig/drivers/net/bonding/bond_main.c
> +++ linux-2.6/drivers/net/bonding/bond_main.c
> @@ -59,6 +59,7 @@
> #include <linux/uaccess.h>
> #include <linux/errno.h>
> #include <linux/netdevice.h>
> +#include <linux/netpoll.h>
> #include <linux/inetdevice.h>
> #include <linux/igmp.h>
> #include <linux/etherdevice.h>
> @@ -430,7 +431,17 @@ int bond_dev_queue_xmit(struct bonding *
> }
>
> skb->priority = 1;
> - dev_queue_xmit(skb);
> +#ifdef CONFIG_NET_POLL_CONTROLLER
> + if (bond->dev->priv_flags & IFF_IN_NETPOLL) {
> + bond->dev->npinfo->netpoll->dev = skb->dev;
> + if (!slave_dev->npinfo)
> + slave_dev->npinfo = bond->dev->npinfo;
> + slave_dev->priv_flags |= IFF_IN_NETPOLL;
> + netpoll_send_skb(bond->dev->npinfo->netpoll, skb);
> + slave_dev->priv_flags &= ~IFF_IN_NETPOLL;
> + } else
> +#endif
> + dev_queue_xmit(skb);
>
> return 0;
> }
> @@ -1324,6 +1335,87 @@ static void bond_detach_slave(struct bon
> bond->slave_cnt--;
> }
>
> +#ifdef CONFIG_NET_POLL_CONTROLLER
> +static bool slaves_support_netpoll(struct net_device *bond_dev)
> +{
> + struct bonding *bond = netdev_priv(bond_dev);
> + struct slave *slave;
> + int i = 0;
> + bool ret = true;
> +
> + read_lock_bh(&bond->lock);
> + bond_for_each_slave(bond, slave, i) {
> + if ((slave->dev->priv_flags & IFF_DISABLE_NETPOLL)
> + || !slave->dev->netdev_ops->ndo_poll_controller)
> + ret = false;
> + }
> + read_unlock_bh(&bond->lock);
> + return i != 0 && ret;
> +}
> +
> +static void bond_poll_controller(struct net_device *bond_dev)
> +{
> + struct bonding *bond = netdev_priv(bond_dev);
> + struct slave *slave;
> + int i;
> +
> + read_lock(&bond->lock);
> + bond_for_each_slave(bond, slave, i) {
> + if (slave->dev->netdev_ops->ndo_poll_controller)
> + netpoll_poll_dev(slave->dev);
> + }
> + read_unlock(&bond->lock);
> +}
> +
> +static void bond_netpoll_setup(struct net_device *bond_dev,
> + struct netpoll_info *npinfo)
> +{
> + struct bonding *bond = netdev_priv(bond_dev);
> + struct slave *slave;
> + int i;
> +
> + write_lock_bh(&bond->lock);
> + bond_for_each_slave(bond, slave, i) {
> + if (slave->dev)
> + slave->dev->npinfo = npinfo;
> + }
> + write_unlock_bh(&bond->lock);
> +}
> +
> +static void bond_netpoll_cleanup(struct net_device *bond_dev)
> +{
> + struct bonding *bond = netdev_priv(bond_dev);
> + struct slave *slave;
> + const struct net_device_ops *ops;
> + int i;
> +
> + write_lock_bh(&bond->lock);
> + bond_dev->npinfo = NULL;
> + bond_for_each_slave(bond, slave, i) {
> + if (slave->dev) {
> + ops = slave->dev->netdev_ops;
> + if (ops->ndo_netpoll_cleanup)
> + ops->ndo_netpoll_cleanup(slave->dev);
> + else
> + slave->dev->npinfo = NULL;
> + }
> + }
> + write_unlock_bh(&bond->lock);
> +}
> +
> +static int bond_netpoll_xmit(struct netpoll *np, struct sk_buff *skb,
> + struct net_device *dev)
> +{
> + int ret;
> +
> + dev->priv_flags |= IFF_IN_NETPOLL;
> + ret = dev->netdev_ops->ndo_start_xmit(skb, dev);
> + np->dev = dev;
> + dev->priv_flags &= ~IFF_IN_NETPOLL;
> + return ret;
> +}
> +#endif
> +
> /*---------------------------------- IOCTL ----------------------------------*/
>
> static int bond_sethwaddr(struct net_device *bond_dev,
> @@ -1741,6 +1833,18 @@ int bond_enslave(struct net_device *bond
> new_slave->state == BOND_STATE_ACTIVE ? "n active" : " backup",
> new_slave->link != BOND_LINK_DOWN ? "n up" : " down");
>
> +#ifdef CONFIG_NET_POLL_CONTROLLER
> + if (slaves_support_netpoll(bond_dev)) {
> + bond_dev->priv_flags &= ~IFF_DISABLE_NETPOLL;
> + if (bond_dev->npinfo)
> + slave_dev->npinfo = bond_dev->npinfo;
> + } else if (!(bond_dev->priv_flags & IFF_DISABLE_NETPOLL)) {
> + bond_dev->priv_flags |= IFF_DISABLE_NETPOLL;
> + pr_info("New slave device %s does not support netpoll\n",
> + slave_dev->name);
> + pr_info("Disabling netpoll support for %s\n", bond_dev->name);
> + }
> +#endif
> /* enslave is successful */
> return 0;
>
> @@ -1924,6 +2028,15 @@ int bond_release(struct net_device *bond
>
> netdev_set_master(slave_dev, NULL);
>
> +#ifdef CONFIG_NET_POLL_CONTROLLER
> + if (slaves_support_netpoll(bond_dev))
> + bond_dev->priv_flags &= ~IFF_DISABLE_NETPOLL;
> + if (slave_dev->netdev_ops->ndo_netpoll_cleanup)
> + slave_dev->netdev_ops->ndo_netpoll_cleanup(slave_dev);
> + else
> + slave_dev->npinfo = NULL;
> +#endif
> +
> /* close slave before restoring its mac address */
> dev_close(slave_dev);
>
> @@ -2032,6 +2145,9 @@ static int bond_release_all(struct net_d
>
> netdev_set_master(slave_dev, NULL);
>
> +#ifdef CONFIG_NET_POLL_CONTROLLER
> + slave_dev->npinfo = NULL;
> +#endif
> /* close slave before restoring its mac address */
> dev_close(slave_dev);
>
> @@ -4424,6 +4540,12 @@ static const struct net_device_ops bond_
> .ndo_vlan_rx_register = bond_vlan_rx_register,
> .ndo_vlan_rx_add_vid = bond_vlan_rx_add_vid,
> .ndo_vlan_rx_kill_vid = bond_vlan_rx_kill_vid,
> +#ifdef CONFIG_NET_POLL_CONTROLLER
> + .ndo_netpoll_setup = bond_netpoll_setup,
> + .ndo_netpoll_xmit = bond_netpoll_xmit,
> + .ndo_netpoll_cleanup = bond_netpoll_cleanup,
> + .ndo_poll_controller = bond_poll_controller,
> +#endif
> };
>
> static void bond_setup(struct net_device *bond_dev)
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox