* [PATCH] bonding: fix bridged bonds in 802.3ad mode
From: Jiri Bohac @ 2011-04-21 18:47 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger, Jay Vosburgh, Andy Gospodarek,
Benjamin Poirier
802.3ad bonding inside a bridge is broken again. Originally fixed by
43aa1920117801fe9ae3d1fad886b62511e09bee, the bug was re-introduced by
1e253c3b8a1aeed51eef6fc366812f219b97de65.
LACP frames must not have their skb->dev changed by the bridging hook.
Signed-off-by: Jiri Bohac <jbohac@suse.cz>
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1514,6 +1514,11 @@ static rx_handler_result_t bond_handle_frame(struct sk_buff **pskb)
memcpy(eth_hdr(skb)->h_dest, bond->dev->dev_addr, ETH_ALEN);
}
+ /* prevent bridging code from mangling and forwarding LACP frames */
+ if (bond->params.mode == BOND_MODE_8023AD &&
+ skb->protocol == htons(ETH_P_SLOW))
+ return RX_HANDLER_PASS;
+
return RX_HANDLER_ANOTHER;
}
--
Jiri Bohac <jbohac@suse.cz>
SUSE Labs, SUSE CZ
^ permalink raw reply
* RE: rtnetlink and many VFs
From: Rose, Gregory V @ 2011-04-21 18:28 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, netdev, sf-linux-drivers
In-Reply-To: <1303409517.3165.39.camel@bwh-desktop>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> On Behalf Of Ben Hutchings
> Sent: Thursday, April 21, 2011 11:12 AM
> To: Rose, Gregory V
> Cc: David Miller; netdev; sf-linux-drivers
> Subject: RE: rtnetlink and many VFs
>
> On Thu, 2011-04-21 at 10:50 -0700, Rose, Gregory V wrote:
> > > -----Original Message-----
> > > From: Ben Hutchings [mailto:bhutchings@solarflare.com]
> > > Sent: Thursday, April 21, 2011 10:40 AM
> > > To: Rose, Gregory V
> > > Cc: David Miller; netdev; sf-linux-drivers
> > > Subject: RE: rtnetlink and many VFs
> > >
>
> > I still feel like eventually the number of VFs will outgrow the
> > capability of a single message to handle, especially when VFs will
> > have the capability of having multiple MAC address and VLAN filters
> > assigned to them. And it seems orthogonal to me to mirror the 'ip
> > link set eth(x) vf (n)' syntax with a 'ip link show eth(x) vf (n)'
> > syntax.
> >
> > That's just me though.
> [...]
>
> I think it would be a useful extension, but we have to keep the current
> API working as far as possible.
Sure, sounds good. I'm working on something that will patch things up for the present use case right now.
- Greg
^ permalink raw reply
* RE: rtnetlink and many VFs
From: Ben Hutchings @ 2011-04-21 18:11 UTC (permalink / raw)
To: Rose, Gregory V; +Cc: David Miller, netdev, sf-linux-drivers
In-Reply-To: <43F901BD926A4E43B106BF17856F07550145FC75D6@orsmsx508.amr.corp.intel.com>
On Thu, 2011-04-21 at 10:50 -0700, Rose, Gregory V wrote:
> > -----Original Message-----
> > From: Ben Hutchings [mailto:bhutchings@solarflare.com]
> > Sent: Thursday, April 21, 2011 10:40 AM
> > To: Rose, Gregory V
> > Cc: David Miller; netdev; sf-linux-drivers
> > Subject: RE: rtnetlink and many VFs
> >
> > On Thu, 2011-04-21 at 10:02 -0700, Rose, Gregory V wrote:
> > > > -----Original Message-----
> > > > From: netdev-owner@vger.kernel.org [mailto:netdev-
> > owner@vger.kernel.org]
> > > > On Behalf Of Ben Hutchings
> > > > Sent: Thursday, April 21, 2011 7:36 AM
> > > > To: David Miller
> > > > Cc: netdev; sf-linux-drivers
> > > > Subject: rtnetlink and many VFs
> > > >
> > >
> > > As more VFs become possible it really needs a fix. I was thinking
> > > about something along the lines of this:
> > >
> > > # ip link show eth(x) vf (n)
> > >
> > > Where eth(x) is the physical function that owns the VFs and (n) is the
> > > specific VF you want information for. That way one could easily
> > > script something that loops through the VFs and gets the information
> > > for each. This really becomes necessary when we start adding
> > > additional MAC and VLAN filters for each VF that need to be displayed.
> > > In that case you can only show a few VFs before you run out of space.
> >
> > I think that what 'ip link show' is doing now seems to be perfectly
> > valid. It allocates a 16K buffer which would be enough if netlink
> > didn't apply this PAGE_SIZE limit to single messages.
>
> Ah, I hadn't seen that it was allocating 16K, that would then be
> enough for 128 VFs but in the future would not be enough for 40Gig (or
> higher speed) devices that might support two or 4 times that many VFs.
There are only 256 available function addresses per PCIe link, so there
can be at most 255 VFs associated with a single PF.
(The function number could be extended further by effectively assigning
multiple bus numbers to a link, but that would be a significantly more
disruptive change than ARI.)
> I still feel like eventually the number of VFs will outgrow the
> capability of a single message to handle, especially when VFs will
> have the capability of having multiple MAC address and VLAN filters
> assigned to them. And it seems orthogonal to me to mirror the 'ip
> link set eth(x) vf (n)' syntax with a 'ip link show eth(x) vf (n)'
> syntax.
>
> That's just me though.
[...]
I think it would be a useful extension, but we have to keep the current
API working as far as possible.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] tg3: Convert u32 flag,flg2,flg3 uses to bitmap
From: Joe Perches @ 2011-04-21 17:51 UTC (permalink / raw)
To: Michael Chan
Cc: Matthew Carlson, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1303406280.8857.13.camel@HP1>
On Thu, 2011-04-21 at 10:18 -0700, Michael Chan wrote:
> On Wed, 2011-04-20 at 23:39 -0700, Joe Perches wrote:
> > @@ -4622,7 +4611,7 @@ static void tg3_tx_recover(struct tg3 *tp)
> > "and include system chipset information.\n");
> >
> > spin_lock(&tp->lock);
> > - tp->tg3_flags |= TG3_FLAG_TX_RECOVERY_PENDING;
> > + tg3_flag_set(tp, TX_RECOVERY_PENDING);
> > spin_unlock(&tp->lock);
> > }
> By using set_bit() now, we can eliminate the spin_lock() here. This
> flag is checked much later when tg3_reset_task() is scheduled to run in
> workqueue, so no memory barrier is needed either.
Sure, but as a separate patch.
^ permalink raw reply
* RE: rtnetlink and many VFs
From: Rose, Gregory V @ 2011-04-21 17:50 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, netdev, sf-linux-drivers
In-Reply-To: <1303407628.3165.30.camel@bwh-desktop>
> -----Original Message-----
> From: Ben Hutchings [mailto:bhutchings@solarflare.com]
> Sent: Thursday, April 21, 2011 10:40 AM
> To: Rose, Gregory V
> Cc: David Miller; netdev; sf-linux-drivers
> Subject: RE: rtnetlink and many VFs
>
> On Thu, 2011-04-21 at 10:02 -0700, Rose, Gregory V wrote:
> > > -----Original Message-----
> > > From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org]
> > > On Behalf Of Ben Hutchings
> > > Sent: Thursday, April 21, 2011 7:36 AM
> > > To: David Miller
> > > Cc: netdev; sf-linux-drivers
> > > Subject: rtnetlink and many VFs
> > >
> >
> > As more VFs become possible it really needs a fix. I was thinking
> > about something along the lines of this:
> >
> > # ip link show eth(x) vf (n)
> >
> > Where eth(x) is the physical function that owns the VFs and (n) is the
> > specific VF you want information for. That way one could easily
> > script something that loops through the VFs and gets the information
> > for each. This really becomes necessary when we start adding
> > additional MAC and VLAN filters for each VF that need to be displayed.
> > In that case you can only show a few VFs before you run out of space.
>
> I think that what 'ip link show' is doing now seems to be perfectly
> valid. It allocates a 16K buffer which would be enough if netlink
> didn't apply this PAGE_SIZE limit to single messages.
Ah, I hadn't seen that it was allocating 16K, that would then be enough for 128 VFs but in the future would not be enough for 40Gig (or higher speed) devices that might support two or 4 times that many VFs. I still feel like eventually the number of VFs will outgrow the capability of a single message to handle, especially when VFs will have the capability of having multiple MAC address and VLAN filters assigned to them. And it seems orthogonal to me to mirror the 'ip link set eth(x) vf (n)' syntax with a 'ip link show eth(x) vf (n)' syntax.
That's just me though.
>
> It is certainly a bug. rtnetlink is the currently favoured API for
> querying and configuring network device settings, but there are now
> valid device settings that cannot be queried.
I'll look into just fixing the bug for now and reserve (at least what I consider to be) future improvements for later.
- Greg
^ permalink raw reply
* RE: rtnetlink and many VFs
From: Ben Hutchings @ 2011-04-21 17:40 UTC (permalink / raw)
To: Rose, Gregory V; +Cc: David Miller, netdev, sf-linux-drivers
In-Reply-To: <43F901BD926A4E43B106BF17856F07550145FC7526@orsmsx508.amr.corp.intel.com>
On Thu, 2011-04-21 at 10:02 -0700, Rose, Gregory V wrote:
> > -----Original Message-----
> > From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> > On Behalf Of Ben Hutchings
> > Sent: Thursday, April 21, 2011 7:36 AM
> > To: David Miller
> > Cc: netdev; sf-linux-drivers
> > Subject: rtnetlink and many VFs
> >
> > My colleagues have been working on SR-IOV support for sfc. The hardware
> > supports up to 127 VFs per port.
> >
> > If we configure all 127 VFs through the net device, an RTM_GETLINK dump
> > will need to include messages describing them, with a total size of:
> >
> > 127 * (sizeof(struct ifla_vf_mac) + sizeof(struct ifla_vf_vlan) +
> > sizeof(struct ifla_vf_tx_rate) + protocol overhead)
> > > 7112
> >
> > These messages are nested within the message describing the device as a
> > whole, so they cannot be split. The maximum size of an outgoing netlink
> > message, based on NLMSG_GOODSIZE, seems to be min(PAGE_SIZE, 8192). So
> > when PAGE_SIZE = 4096 it is simply impossible to dump information about
> > such a device!
> >
> > I think it needs to be made possible to grow a netlink skb during
> > generation of the first message. Userspace may still be unable to
> > receive the large message but at least it has a chance.
>
> I've been looking at this one too. The limit seems to be about 40 or
> so in the most common case.
Right. When Steve Hodgson investigated this here, he found that 46 VFs
would fit.
> My netlink fu is weak but I've been looking at the code in iproute2/ip
> and netlink to see what we can do about it.
>
> As more VFs become possible it really needs a fix. I was thinking
> about something along the lines of this:
>
> # ip link show eth(x) vf (n)
>
> Where eth(x) is the physical function that owns the VFs and (n) is the
> specific VF you want information for. That way one could easily
> script something that loops through the VFs and gets the information
> for each. This really becomes necessary when we start adding
> additional MAC and VLAN filters for each VF that need to be displayed.
> In that case you can only show a few VFs before you run out of space.
I think that what 'ip link show' is doing now seems to be perfectly
valid. It allocates a 16K buffer which would be enough if netlink
didn't apply this PAGE_SIZE limit to single messages.
> In any case I've been working on an RFC patch for this and hope to
> have it soon. I consider this a pretty serious limitation and one
> could even view it as a bug.
It is certainly a bug. rtnetlink is the currently favoured API for
querying and configuring network device settings, but there are now
valid device settings that cannot be queried.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH BUG-FIX] ipv6: udp: fix the wrong headroom check
From: David Miller @ 2011-04-21 17:39 UTC (permalink / raw)
To: herbert; +Cc: shanwei, kuznet, pekkas, jmorris, yoshfuji, kaber, netdev
In-Reply-To: <20110420105007.GA16248@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed, 20 Apr 2011 18:50:07 +0800
> On Wed, Apr 20, 2011 at 04:52:49PM +0800, Shan Wei wrote:
>> At this point, skb->data points to skb_transport_header.
>> So, headroom check is wrong.
>>
>> For some case:bridge(UFO is on) + eth device(UFO is off),
>> there is no enough headroom for IPv6 frag head.
>> But headroom check is always false.
>>
>> This will bring about data be moved to there prior to skb->head,
>> when adding IPv6 frag header to skb.
>>
>> Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
>
> Ouch.
>
> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next-2.6 0/3] new SCTP sockets APIs
From: David Miller @ 2011-04-21 17:36 UTC (permalink / raw)
To: yjwei; +Cc: netdev, linux-sctp
In-Reply-To: <4DABAEF1.1010506@cn.fujitsu.com>
From: Wei Yongjun <yjwei@cn.fujitsu.com>
Date: Mon, 18 Apr 2011 11:24:33 +0800
> This patchset implement some new sockets APIs for net-next-2.6.
>
> Wei Yongjun (3):
> sctp: implement socket option SCTP_GET_ASSOC_ID_LIST
> sctp: change auth event type name to SCTP_AUTHENTICATION_EVENT
> sctp: implement event notification SCTP_SENDER_DRY_EVENT
All 3 patches applied, thanks.
^ permalink raw reply
* [PATCH] [RFC] davinci_emac: don't WARN_ON cpdma_chan_submit -ENOMEM
From: Ben Gardiner @ 2011-04-21 17:30 UTC (permalink / raw)
To: netdev; +Cc: davinci-linux-open-source, Sriramakrishnan A G
The current implementation of emac_rx_handler, when the host is
flooded, will result in a great deal of WARNs on the console; due to
the return value of cpdma_chan_submit. This function can error with
EINVAL and ENOMEM; the former when the channel is in an invalid
state, in which case the caller is in error. The latter when a cpdma
descriptor cannot be allocated.
When flooded, cpdma_chan_submit will return -ENOMEM;
treat the inability to allocate a cpdma descriptor as an rx error
similar in behaviour to when emac_rx_alloc returns NULL.
No Signed-off-by yet; not complete fix (see below).
CC: Sriramakrishnan A G <srk@ti.com>
---
I'm new to network drivers -- and kernel development, really. I'd be
happy to receive feedback on this approach of resolving the -ENOMEM
when flooded. Is there a more conventional approach? Shoud these frames
be recorded as 'dropped'?
Testing was performed on da850evm both with and without "net:
davinci_emac: fix spinlock bug with dma channel cleanup" from
Sriramakrishnan A G applied. The behaviour was the same: the emac is
not able to receive any frames after being flooded -- but it can still
send. I would appreciate any insight into the potential causes of the
lockup.
Best Regards,
Ben Gardiner
Nanometrics Inc.
http://www.nanometrics.ca
---
drivers/net/davinci_emac.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 7018bfe..17c48d6 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -1037,8 +1037,12 @@ static void emac_rx_handler(void *token, int len, int status)
recycle:
ret = cpdma_chan_submit(priv->rxchan, skb, skb->data,
skb_tailroom(skb), GFP_KERNEL);
- if (WARN_ON(ret < 0))
+ WARN_ON(ret == -EINVAL);
+ if (ret < 0) {
+ if (netif_msg_rx_err(priv) && net_ratelimit())
+ dev_err(emac_dev, "failed cpdma submit\n");
dev_kfree_skb_any(skb);
+ }
}
static void emac_tx_handler(void *token, int len, int status)
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] tg3: Convert u32 flag,flg2,flg3 uses to bitmap
From: Michael Chan @ 2011-04-21 17:18 UTC (permalink / raw)
To: Joe Perches
Cc: Matthew Carlson, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <02bf2aa5c08514641ecbe7c39ef976918fad036c.1303367730.git.joe@perches.com>
On Wed, 2011-04-20 at 23:39 -0700, Joe Perches wrote:
> @@ -4622,7 +4611,7 @@ static void tg3_tx_recover(struct tg3 *tp)
> "and include system chipset information.\n");
>
> spin_lock(&tp->lock);
> - tp->tg3_flags |= TG3_FLAG_TX_RECOVERY_PENDING;
> + tg3_flag_set(tp, TX_RECOVERY_PENDING);
> spin_unlock(&tp->lock);
> }
>
By using set_bit() now, we can eliminate the spin_lock() here. This
flag is checked much later when tg3_reset_task() is scheduled to run in
workqueue, so no memory barrier is needed either.
Thanks.
^ permalink raw reply
* RE: rtnetlink and many VFs
From: Rose, Gregory V @ 2011-04-21 17:02 UTC (permalink / raw)
To: Ben Hutchings, David Miller; +Cc: netdev, sf-linux-drivers
In-Reply-To: <1303396576.3165.13.camel@bwh-desktop>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> On Behalf Of Ben Hutchings
> Sent: Thursday, April 21, 2011 7:36 AM
> To: David Miller
> Cc: netdev; sf-linux-drivers
> Subject: rtnetlink and many VFs
>
> My colleagues have been working on SR-IOV support for sfc. The hardware
> supports up to 127 VFs per port.
>
> If we configure all 127 VFs through the net device, an RTM_GETLINK dump
> will need to include messages describing them, with a total size of:
>
> 127 * (sizeof(struct ifla_vf_mac) + sizeof(struct ifla_vf_vlan) +
> sizeof(struct ifla_vf_tx_rate) + protocol overhead)
> > 7112
>
> These messages are nested within the message describing the device as a
> whole, so they cannot be split. The maximum size of an outgoing netlink
> message, based on NLMSG_GOODSIZE, seems to be min(PAGE_SIZE, 8192). So
> when PAGE_SIZE = 4096 it is simply impossible to dump information about
> such a device!
>
> I think it needs to be made possible to grow a netlink skb during
> generation of the first message. Userspace may still be unable to
> receive the large message but at least it has a chance.
I've been looking at this one too. The limit seems to be about 40 or so in the most common case. My netlink fu is weak but I've been looking at the code in iproute2/ip and netlink to see what we can do about it.
As more VFs become possible it really needs a fix. I was thinking about something along the lines of this:
# ip link show eth(x) vf (n)
Where eth(x) is the physical function that owns the VFs and (n) is the specific VF you want information for. That way one could easily script something that loops through the VFs and gets the information for each. This really becomes necessary when we start adding additional MAC and VLAN filters for each VF that need to be displayed. In that case you can only show a few VFs before you run out of space.
In any case I've been working on an RFC patch for this and hope to have it soon. I consider this a pretty serious limitation and one could even view it as a bug.
- Greg
Greg Rose
LAD Division
Intel Corp.
^ permalink raw reply
* Re: [PATCH] tg3: Convert u32 flag,flg2,flg3 uses to bitmap
From: Joe Perches @ 2011-04-21 16:49 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Matt Carlson, Michael Chan, netdev, linux-kernel
In-Reply-To: <1303374696.3685.14.camel@edumazet-laptop>
On Thu, 2011-04-21 at 10:31 +0200, Eric Dumazet wrote:
> Le mercredi 20 avril 2011 à 23:39 -0700, Joe Perches a écrit :
> > Using a bitmap instead of separate u32 flags allows a consistent, simpler
[]
> Use an enum ?
No strong preference.
If it's an enum .c file will change.
> Why first value is 1 and not 0 ?
Should be 0.
> > +#define TG3_FLAGS 74 /* Set to number of flags */
> Also you need to make TG3_FLAGS be (last_flag_value + 1) or you could
> miss one long in bitmap.
Right. Thanks for comments Eric.
I'll wait for Matt to comment before resubmitting.
^ permalink raw reply
* Re: rfkill-input to be removed
From: Marco Chiappero @ 2011-04-21 16:45 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev
In-Reply-To: <1303402951.3597.27.camel@jlt3.sipsolutions.net>
Il 21/04/2011 18:22, Johannes Berg ha scritto:
> Yeah we noticed this before with some other drivers. The persistent
> stuff seems to only be suitable for a small number of semantics.
Sorry, what do you mean exactly? The persistent stuff seems to work well
with those notebooks.
> Frankly, I don't think we're ready for this yet, most distros don't yet
> ship the rfkill daemon.
Ok, in the meantime I'm going to avoid the SW_RFKILL_ALL switch event
forwarding, unless the master_switch_mode=1 is going to be changed to
honor the stored power state on drivers loading as well, not only when
moving the "kill all" switch (it seems that on boot every device is
always turned on, which is very annoying).
^ permalink raw reply
* Re: RPS will assign different smp_processor_id for the same packet?
From: zhou rui @ 2011-04-21 16:29 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev@vger.kernel.org
In-Reply-To: <1303403112.3685.61.camel@edumazet-laptop>
On Friday, April 22, 2011, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le jeudi 21 avril 2011 à 18:08 +0200, Eric Dumazet a écrit :
>> Le jeudi 21 avril 2011 à 23:50 +0800, zhou rui a écrit :
>> > kernel 2.6.36.4
>> > CONFIG_RPS=y but not set the cpu mask
>> >
>> > /sys/class/net/eth1/queues/rx-0 # cat rps_cpus
>> > 00
>> >
>> > register a hook func:
>> > prot_hook.func = packet_rcv;
>> > prot_hook.type = htons(ETH_P_ALL);
>> > dev_add_pack(&prot_hook);
>> >
>> >
>> > replay the same traffic in very slow speed, printk the
>> > smp_processor_id in packet_rcv():
>> > first time:
>> > cpu=4
>> > cpu=3
>> > cpu=6
>> > cpu=7
>> >
>> > second time:
>> > cpu=7
>> > cpu=1
>> > cpu=5
>> > cpu=2
>> >
>> > is it normal?
>>
>> Yes it is.
>>
>> What would you expect ?
>>
>
> If rps_cpus contains only '0' bits, it basically means RPS is not active
> for this input queue.
>
> CPU is therefore not changed : The cpu handling NAPI on your network
> device directly calls upper linux stack.
>
> Seeing your traces, it also means your device spreads its interrupts on
> many different cpus, this might be not optimal.
>
> Check /proc/irq/{irq_number}/smp_affinity, it probably contains "ff"
>
>
>
>
Thanks,just saw this email
^ permalink raw reply
* Re: RPS will assign different smp_processor_id for the same packet?
From: zhou rui @ 2011-04-21 16:27 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev@vger.kernel.org
In-Reply-To: <1303402094.3685.54.camel@edumazet-laptop>
On Friday, April 22, 2011, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le jeudi 21 avril 2011 à 23:50 +0800, zhou rui a écrit :
>> kernel 2.6.36.4
>> CONFIG_RPS=y but not set the cpu mask
>>
>> /sys/class/net/eth1/queues/rx-0 # cat rps_cpus
>> 00
>>
>> register a hook func:
>> prot_hook.func = packet_rcv;
>> prot_hook.type = htons(ETH_P_ALL);
>> dev_add_pack(&prot_hook);
>>
>>
>> replay the same traffic in very slow speed, printk the
>> smp_processor_id in packet_rcv():
>> first time:
>> cpu=4
>> cpu=3
>> cpu=6
>> cpu=7
>>
>> second time:
>> cpu=7
>> cpu=1
>> cpu=5
>> cpu=2
>>
>> is it normal?
>
> Yes it is.
>
> What would you expect ?
>
>
>
I want a same CPU for same packet,
If I echo ff >rps_cpu,will I get it?
And the design idea for different CPU in rps?
I understand nic will assign same rxq for packet has same hash
^ permalink raw reply
* Re: [PATCHv4] usbnet: Resubmit interrupt URB once if halted
From: Alan Stern @ 2011-04-21 16:27 UTC (permalink / raw)
To: Paul Stewart; +Cc: netdev, linux-usb, davem, greg
In-Reply-To: <BANLkTik7Da6K4Fn7=dpo8RwwctCp8kV_iw@mail.gmail.com>
On Thu, 21 Apr 2011, Paul Stewart wrote:
> I'm trying to handle two separate issues, one of which I can't say I
> fully understand. The first, which is the most straightforward, is
> for systems in which USB devices remained powered across
> suspend-resume. For this case for sure, we don't need a flag. The
> interrupt URBs are halted (either done so by the HCD as I've observed,
> or the drive can choose to kill them in usbnet_suspend()). On system
> resume, we're guaranteed URBs have stopped, and we can just submit
> one.
Okay, good.
> In a second scenario, for other systems USB devices go unpowered
> during suspend.
As happens during hibernation, for example.
> At resume time, there's a quick succession where the
> device appears to detach and reattach and enumerate.
Right. It's called reset-resume, and drivers have a special method for
it, distinct from regular resume. In theory it shouldn't make any
difference.
> This is where
> things get strange. It appears that since the enumeration happens in
> the course of system resume, when usbnet_open() gets called, and
> usb_autopm_get_interface(), there's a call path that leads to
> usbnet_resume().
Only if the interface was suspended when usbnet_open() was called. It
might have gotten suspended automatically following the system resume,
if it wasn't in use. But this should work out the same whether or not
there was a reset-rseume.
> If there's no flag, then we submit the interrupt urb
> from usbnet_resume(), so the submit_urb() in usbnet_open() fails in an
> error. This makes actions like "ifconfig eth0 up" fail on the
> interface after resume from suspend.
The driver needs better coordination between open/stop and
resume/suspend. The interrupt and receive URBs are supposed to be
active whenever the interface is up and not suspended, right? Which
means that usbnet_resume() shouldn't submit anything if the interface
isn't up.
Alan Stern
^ permalink raw reply
* Re: RPS will assign different smp_processor_id for the same packet?
From: Eric Dumazet @ 2011-04-21 16:25 UTC (permalink / raw)
To: zhou rui; +Cc: netdev
In-Reply-To: <1303402094.3685.54.camel@edumazet-laptop>
Le jeudi 21 avril 2011 à 18:08 +0200, Eric Dumazet a écrit :
> Le jeudi 21 avril 2011 à 23:50 +0800, zhou rui a écrit :
> > kernel 2.6.36.4
> > CONFIG_RPS=y but not set the cpu mask
> >
> > /sys/class/net/eth1/queues/rx-0 # cat rps_cpus
> > 00
> >
> > register a hook func:
> > prot_hook.func = packet_rcv;
> > prot_hook.type = htons(ETH_P_ALL);
> > dev_add_pack(&prot_hook);
> >
> >
> > replay the same traffic in very slow speed, printk the
> > smp_processor_id in packet_rcv():
> > first time:
> > cpu=4
> > cpu=3
> > cpu=6
> > cpu=7
> >
> > second time:
> > cpu=7
> > cpu=1
> > cpu=5
> > cpu=2
> >
> > is it normal?
>
> Yes it is.
>
> What would you expect ?
>
If rps_cpus contains only '0' bits, it basically means RPS is not active
for this input queue.
CPU is therefore not changed : The cpu handling NAPI on your network
device directly calls upper linux stack.
Seeing your traces, it also means your device spreads its interrupts on
many different cpus, this might be not optimal.
Check /proc/irq/{irq_number}/smp_affinity, it probably contains "ff"
^ permalink raw reply
* Re: rfkill-input to be removed
From: Johannes Berg @ 2011-04-21 16:22 UTC (permalink / raw)
To: Marco Chiappero; +Cc: netdev
In-Reply-To: <4DAFEAA7.5090003@absence.it>
On Thu, 2011-04-21 at 10:28 +0200, Marco Chiappero wrote:
> While working on the the sony-laptop driver, adding support for
> persistent rfkill state storing and adding the SW_RFKILL_ALL switch
> event forwarding to the input core to notify userspace, I realized that
> rfkill-input interferes with correct behavior of the driver, vanishing
> the hardware device state storing.
Yeah we noticed this before with some other drivers. The persistent
stuff seems to only be suitable for a small number of semantics.
> Then, looking at
> Documentation/feature-removal-schedule.txt I realized that rfkill-input
> was scheduled to be removed in 2.6.33, but it's still there in 2.6.39.
> Please remove that code as soon as possible, rfkill input events should
> be handled by user space tools.
Frankly, I don't think we're ready for this yet, most distros don't yet
ship the rfkill daemon.
johannes
^ permalink raw reply
* Re: RPS will assign different smp_processor_id for the same packet?
From: Eric Dumazet @ 2011-04-21 16:08 UTC (permalink / raw)
To: zhou rui; +Cc: netdev
In-Reply-To: <BANLkTimvuGKYuiV_ngTo4wtqhNix4iMfmA@mail.gmail.com>
Le jeudi 21 avril 2011 à 23:50 +0800, zhou rui a écrit :
> kernel 2.6.36.4
> CONFIG_RPS=y but not set the cpu mask
>
> /sys/class/net/eth1/queues/rx-0 # cat rps_cpus
> 00
>
> register a hook func:
> prot_hook.func = packet_rcv;
> prot_hook.type = htons(ETH_P_ALL);
> dev_add_pack(&prot_hook);
>
>
> replay the same traffic in very slow speed, printk the
> smp_processor_id in packet_rcv():
> first time:
> cpu=4
> cpu=3
> cpu=6
> cpu=7
>
> second time:
> cpu=7
> cpu=1
> cpu=5
> cpu=2
>
> is it normal?
Yes it is.
What would you expect ?
^ permalink raw reply
* Re: r8169 doesn't report link state correctly.
From: Dan Williams @ 2011-04-21 15:55 UTC (permalink / raw)
To: Ben Greear; +Cc: Francois Romieu, netdev
In-Reply-To: <4DAF569E.1040507@candelatech.com>
On Wed, 2011-04-20 at 14:56 -0700, Ben Greear wrote:
> On 04/20/2011 12:14 PM, Francois Romieu wrote:
> > François Romieu<romieu@fr.zoreil.com> :
> >> On Mon, Apr 11, 2011 at 01:09:19PM -0700, Ben Greear wrote:
> >>> I notice that in kernel 2.6.38-wl, the realtek 8169 NIC doesn't
> >>> report link down when in fact there is no cable connected. Instead,
> > [...]
> >> Thanks for the report. I'll try it tomorrow or friday.
> >
> > I have not been able to notice it with a current kernel.
> >
> > I'd welcome the XID of the 8169 NIC (see dmesg) and a short explanation
> > (no cable from boot ? cable removed after ifconfig up ? brand / ability
> > of the switch / hub ?).
>
> Well, as luck would have it, my system will boot today's upstream
> kernel (39-rc4+). And, I no longer see the problem in that release,
> so it seems it is fixed (or harder to reproduce that I thought).
>
> Basically, I was seeing it claim to have link in 'ethtool' output
> when there was no cable connected. It did go to 10Mbps/half duplex
> link speed when un-plugged. It showed full 1Gbps link when plugged
> in.
>
> I'll let you know if I see this again.
I just had a user run into this bug yesterday on 2.6.38.3 and he
described the exact symptoms in
https://bugzilla.kernel.org/show_bug.cgi?id=33782 . Essentially:
- cable plugged in
- ifconfig eth0 down
- wait a few seconds
- ifconfig eth0 up
- ifconfig eth0 (no LOWER_UP is shown)
If the cable is plugged in, and the device is UP, then we should expect
LOWER_UP indicating the device has a carrier. But that's not happening.
If there's any way to isolate a fix and push that fix to stable@ that
would be great...
Dan
^ permalink raw reply
* RPS will assign different smp_processor_id for the same packet?
From: zhou rui @ 2011-04-21 15:50 UTC (permalink / raw)
To: netdev
kernel 2.6.36.4
CONFIG_RPS=y but not set the cpu mask
/sys/class/net/eth1/queues/rx-0 # cat rps_cpus
00
register a hook func:
prot_hook.func = packet_rcv;
prot_hook.type = htons(ETH_P_ALL);
dev_add_pack(&prot_hook);
replay the same traffic in very slow speed, printk the
smp_processor_id in packet_rcv():
first time:
cpu=4
cpu=3
cpu=6
cpu=7
second time:
cpu=7
cpu=1
cpu=5
cpu=2
is it normal?
thanks
rui
^ permalink raw reply
* Re: rfkill-input to be removed
From: Dan Williams @ 2011-04-21 15:51 UTC (permalink / raw)
To: Marco Chiappero; +Cc: netdev, johannes
In-Reply-To: <4DB03586.3040702@absence.it>
On Thu, 2011-04-21 at 15:47 +0200, Marco Chiappero wrote:
> Il 21/04/2011 10:28, Marco Chiappero ha scritto:
> > Please remove that code as soon as possible, rfkill input events should
> > be handled by user space tools.
>
> About this topic, I've created a patch right now, you can find it here:
> http://www.absence.it/vaio-acpi/source/patches/rfkill-input.patch
> Does it look fine?
You'll want to follow the patch submission guidelines:
http://linux.yyz.us/patch-format.html
before people will look at the patch, because many of the people who
would look at it are quite busy. That means:
1) use a subject like "[PATCH] rfkill-input: remove deprecated module"
2) Add your Signed-off-by: Your Name <your email>
3) paste your patch *inline*, not as an attachment, and make *sure* to
use the "preformat" or whatever option when you do, so that your mailer
doesn't wrap long lines
Dan
> Moreover, using checkpatch.pl I've found 3 coding style errors, I'm
> attaching a patch to fix them (apply this one first).
>
> And just one last thing: as there is no configuration option inside the
> menu, shouldn't we change the "menuconfig RFKILL" line to "config
> RFKILL" inside net/rfkill/Kconfig?
^ permalink raw reply
* Re: ipqueue allocation failure.
From: Patrick McHardy @ 2011-04-21 15:13 UTC (permalink / raw)
To: Dave Jones; +Cc: netdev
In-Reply-To: <20110420014221.GC26949@redhat.com>
Am 20.04.2011 03:42, schrieb Dave Jones:
> Not catastrophic, but ipqueue seems to be too trusting of what it gets
> passed from userspace, and passes it on down to the page allocator,
> where it will spew warnings if the page order is too high.
>
> __ipq_rcv_skb has several checks for lengths too small, but doesn't
> seem to have any for oversized ones. I'm not sure what the maximum
> we should check for is. I'll code up a diff if anyone has any ideas
> on a sane maximum.
A sane maximum seems to be 2^16 - 1, the maximum size of an IPv4 packet.
Please also update ip6queue and nfnetlink_queue.
^ permalink raw reply
* Re: [PATCHv4] usbnet: Resubmit interrupt URB once if halted
From: Paul Stewart @ 2011-04-21 14:58 UTC (permalink / raw)
To: Alan Stern; +Cc: netdev, linux-usb, davem, greg
In-Reply-To: <Pine.LNX.4.44L0.1104210958560.1939-100000@iolanthe.rowland.org>
On Thu, Apr 21, 2011 at 7:03 AM, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Tue, 19 Apr 2011, Paul Stewart wrote:
>
>> Set a flag if the interrupt URB completes with ENOENT as this
>> occurs legitimately during system suspend. When the
>> usbnet_resume is called, test this flag and try once to resubmit
>> the interrupt URB.
>
> I still don't think this is the best way to go.
>
>> This version of the patch moves the urb submit directly into
>> usbnet_resume. Is it okay to submit a GFP_KERNEL urb from
>> usbnet_resume()?
>
> Yes, it is.
>
>> Signed-off-by: Paul Stewart <pstew@chromium.org>
>> ---
>> drivers/net/usb/usbnet.c | 13 ++++++++++++-
>> include/linux/usb/usbnet.h | 1 +
>> 2 files changed, 13 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
>> index 02d25c7..3651a48 100644
>> --- a/drivers/net/usb/usbnet.c
>> +++ b/drivers/net/usb/usbnet.c
>> @@ -482,6 +482,7 @@ static void intr_complete (struct urb *urb)
>> case -ESHUTDOWN: /* hardware gone */
>> if (netif_msg_ifdown (dev))
>> devdbg (dev, "intr shutdown, code %d", status);
>> + set_bit(EVENT_INTR_HALT, &dev->flags);
>
> Is this new flag really needed?
>
>> return;
>>
>> /* NOTE: not throttling like RX/TX, since this endpoint
>> @@ -1294,9 +1295,19 @@ int usbnet_resume (struct usb_interface *intf)
>> {
>> struct usbnet *dev = usb_get_intfdata(intf);
>>
>> - if (!--dev->suspend_count)
>> + if (!--dev->suspend_count) {
>> tasklet_schedule (&dev->bh);
>>
>> + /* resubmit interrupt URB if it was halted by suspend */
>> + if (dev->interrupt && netif_running(dev->net) &&
>> + netif_device_present(dev->net) &&
>> + test_bit(EVENT_INTR_HALT, &dev->flags)) {
>
> Why do you need the test_bit()? If the other conditions are all true,
> don't you want to resubmit the interrupt URB regardless?
I'm trying to handle two separate issues, one of which I can't say I
fully understand. The first, which is the most straightforward, is
for systems in which USB devices remained powered across
suspend-resume. For this case for sure, we don't need a flag. The
interrupt URBs are halted (either done so by the HCD as I've observed,
or the drive can choose to kill them in usbnet_suspend()). On system
resume, we're guaranteed URBs have stopped, and we can just submit
one.
In a second scenario, for other systems USB devices go unpowered
during suspend. At resume time, there's a quick succession where the
device appears to detach and reattach and enumerate. This is where
things get strange. It appears that since the enumeration happens in
the course of system resume, when usbnet_open() gets called, and
usb_autopm_get_interface(), there's a call path that leads to
usbnet_resume(). If there's no flag, then we submit the interrupt urb
from usbnet_resume(), so the submit_urb() in usbnet_open() fails in an
error. This makes actions like "ifconfig eth0 up" fail on the
interface after resume from suspend.
>
>> + clear_bit(EVENT_INTR_HALT, &dev->flags);
>> + usb_submit_urb(dev->interrupt, GFP_KERNEL);
>> + }
>> + }
>> +}
>> +
>> return 0;
>> }
>
> Alan Stern
>
>
^ permalink raw reply
* Re: [PATCH v5] net: bnx2x: convert to hw_features
From: Eric Dumazet @ 2011-04-21 14:52 UTC (permalink / raw)
To: Michał Mirosław; +Cc: netdev, Vladislav Zolotarov, Eilon Greenstein
In-Reply-To: <20110412193823.0823213A65@rere.qmqm.pl>
Le mardi 12 avril 2011 à 21:38 +0200, Michał Mirosław a écrit :
> Since ndo_fix_features callback is postponing features change when
> bp->recovery_state != BNX2X_RECOVERY_DONE, netdev_update_features()
> has to be called again when this condition changes. Previously,
> ethtool_ops->set_flags callback returned -EBUSY in that case
> (it's not possible in the new model).
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
>
> v5: - don't delay set_features, as it's rtnl_locked - same as recovery process
> v4: - complete bp->rx_csum -> NETIF_F_RXCSUM conversion
> - add check for failed ndo_set_features in ndo_open callback
> v3: - include NETIF_F_LRO in hw_features
> - don't call netdev_update_features() if bnx2x_nic_load() failed
> v2: - comment in ndo_fix_features callback
> ---
Hi guys
I am not sure its related to these changes, but I now have in
net-next-2.6 :
[ 23.674263] ------------[ cut here ]------------
[ 23.674266] WARNING: at net/core/dev.c:1318 dev_disable_lro+0x83/0x90()
[ 23.674270] Hardware name: ProLiant BL460c G6
[ 23.674273] Modules linked in: tg3 libphy sg
[ 23.674280] Pid: 3070, comm: sysctl Tainted: G W 2.6.39-rc2-01242-g3ef22b9-dirty #669
[ 23.674282] Call Trace:
[ 23.674285] [<ffffffff813b94f3>] ? dev_disable_lro+0x83/0x90
[ 23.674291] [<ffffffff81042c9b>] warn_slowpath_common+0x8b/0xc0
[ 23.674298] [<ffffffff81042ce5>] warn_slowpath_null+0x15/0x20
[ 23.674304] [<ffffffff813b94f3>] dev_disable_lro+0x83/0x90
[ 23.674309] [<ffffffff81429789>] devinet_sysctl_forward+0x199/0x210
[ 23.674313] [<ffffffff814296e4>] ? devinet_sysctl_forward+0xf4/0x210
[ 23.674318] [<ffffffff8104e712>] ? capable+0x12/0x20
[ 23.674324] [<ffffffff81168f45>] proc_sys_call_handler+0xb5/0xd0
[ 23.674328] [<ffffffff81168f6f>] proc_sys_write+0xf/0x20
[ 23.674334] [<ffffffff81105f39>] vfs_write+0xc9/0x170
[ 23.674339] [<ffffffff81106550>] sys_write+0x50/0x90
[ 23.674345] [<ffffffff814b95a0>] sysenter_dispatch+0x7/0x33
[ 23.674350] ---[ end trace 051ec497c66b228e ]---
Thanks
^ 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