* Re: [PATCH 04/14] bna: Add Multiple Tx Queue Support
From: John Fastabend @ 2011-08-17 5:47 UTC (permalink / raw)
To: Rasesh Mody
Cc: Ben Hutchings, davem@davemloft.net, netdev@vger.kernel.org,
Adapter Linux Open SRC Team, Gurunatha Karaje
In-Reply-To: <E5313AF6F2BFD14293E5FD0F94750F86A94D9953ED@HQ1-EXCH01.corp.brocade.com>
On 8/16/2011 7:14 PM, Rasesh Mody wrote:
>> From: John Fastabend [mailto:john.r.fastabend@intel.com]
>> Sent: Tuesday, August 16, 2011 5:18 PM
>>
>> On 8/16/2011 4:43 PM, Ben Hutchings wrote:
>>> On Tue, 2011-08-16 at 16:32 -0700, Rasesh Mody wrote:
>>>>> From: Ben Hutchings [mailto:bhutchings@solarflare.com]
>>>>> Sent: Tuesday, August 16, 2011 2:49 PM
>>>>>
>>>>> On Tue, 2011-08-16 at 14:19 -0700, Rasesh Mody wrote:
>>>>>> Change details:
>>>>>> - Add macros bna_prio_allow, bna_default_nw_prio, bna_iscsi_prio,
>>>>>> bna_is_iscsi_over_cee
>>>>>> - Added support for multipe Tx queues with a separate iSCSI Tx
>> queue
>>>>> based
>>>>>> on the default value of iSCSI port number. The feature is
>> supported
>>>>> based
>>>>>> on the underlying hardware and enabled for DCB (CEE) mode only.
>>>>>> - Allocate multiple TxQ resource in netdev
>>>>>> - Implement bnad_tx_select_queue() which enables the correct
>>>>> selection of
>>>>>> TxQ Id (and tcb). This function is called either by the kernel
>> to
>>>>> channel
>>>>>> packets to the right TxQ
>>>>>> - bnad_tx_select_queue() returns priority, while only a few
>> packets
>>>>> during
>>>>>> transition could have wrong priority, all will be associated
>> with a
>>>>> valid
>>>>>> non-NULL tcb.
>>>>>> - Implement bnad_iscsi_tcb_get() and BNAD_IS_ISCSI_PKT() for iSCSI
>>>>> packet
>>>>>> inspection and retrieval of tcb corresponding to the iSCSI
>>>>> priority.
>>>>>> - Construction of priority indirection table to be used by bnad to
>>>>> direct
>>>>>> packets into TxQs
>>>>> [...]
>>>>>
>>>>> You probably should implement TX priority classes through the
>>>>> ndo_setup_tc operation, not ndo_select_queue.
>>>>
>>>> The reason we went with ndo_select_queue is due to the need for
>> mapping
>>>> iSCSI packets (TCP port 3260) to a priority derived from DCB
>> configuration.
>>>> Here the iSCSI packets may not have any tc defined in the packet
>> header.
>>>
>>> There is an skb priority, which is derived from the socket priority
>>> option (SO_PRIORITY). If you implement ndo_setup_tc then the
>> networking
>>> core will take care of mapping the skb priority onto a different queue
>>> (or range of queues).
>>>
>>> I don't know whether the socket priority option is easily configurable
>>> for the existing iSCSI implementations. But looking at port numbers
>>> really doesn't seem like the right way to do this.
>>>
>>> Ben.
>>>
>>
>> At least open-iscsi supports DCB by listening to the RTNLGRP_DCB for
>> events.
>> These are generated with dcbnl_cee_notify and dcbnl_ieee_notify. To
>> support
>> this in your driver you need to call dcb_setapp() or dcb_ieee_setapp()
>> to
>> add the application data and follow this with the appropriate notify
>> call.
>> Then assuming you do the necessary tc setup work the stack will handle
>> the
>> mapping of priority to queues.
>
> This is how iSCSI over DCB feature is expected to works in BNA driver:-
> FW running in the BNA adapter implements the DCB protocol. It learns the
> iSCSI priority from the switch through iSCSI TLV exchange. BNA driver
> extracts the iSCSI priority from the FW that needs to be used for iSCSI
> packets.
Up to here this is fine. What I was suggesting was to then use the
dcb_setapp() routines to program the iSCSI TLV and generate an event
so any user space applications listening to DCB events could handle
this. It would also be nice if your driver notified user space of
any PG or PFC changes as well. Then management agents (lldpad) could
use the DCB attributes to make policy decisions.
> For every outgoing packet, BNA driver does a TCP header
> inspection to classify iSCSI packet and attach right 802.1q priority &
> send it on the correct TX queue.
>
> This is expected to work with iSCSI applications that do not configure the
> priority with SO_PRIORITY - here the iSCSI priority configuration actually
> comes from the switch to the adapter.
>
Although this works I don't think it is optimal for a few reason. Your
L2 driver is inspecting TCP frames which is bad layering IMHO. The
iSCSI port number is hard coded into the driver so it will only work
with the well known port number. Also it adds more driver specific
behavior into select_queue() where I think the trend is to try to
use select_queue() less not more.
To address iSCSI applications that do not configure the priority
we could either work on adding the DCB hooks needed in those
applications. Or look at adding a hook in the qdisc layer to
to do what your select_queue() hook does here. I started prototyping
this awhile ago but this requires running the packet classifiers
and associated actions before picking a queue assuming you want
to use mq or mqprio. I hope to get back to this soon I have some
more details to flush out wrt this and need to run it by some other
folks to make sure its a sane idea.
> The goal of this iSCSI priority is:
> a) adapter applies prioritized scheduling for packets in its egress - to
> guarantee minimum bandwidth as per ETS
> b) packets are tagged with right priority so that switch can also identify
> and guarantee BW on its egress.
Correct. This is the same for other drivers that support DCB and
use tc_setup as Ben suggested. See the bnx2x driver for an example
that also uses a FW based LLDP engine and does this.
>
> Hope this explains.
I think the one valid item is the unsupported applications but
hopefully that can be addressed. Thanks for the details.
John.
>
> Thanks,
> Rasesh
^ permalink raw reply
* Re: [Bugme-new] [Bug 41152] New: kernel 3.0 and above fails to handle vlan id 0 (802.1p) packets properly without hardware acceleration
From: Mike Auty @ 2011-08-17 6:36 UTC (permalink / raw)
To: Jiri Pirko; +Cc: Andrew Morton, bugme-daemon, netdev
In-Reply-To: <20110817053737.GA1936@minipsycho>
On 17/08/11 06:37, Jiri Pirko wrote:
>
> Hi Mike. May I ask what NIC are you seeing the regression on?
> It may have something to do with dev->vlangrp and ndo_vlan_add/kill_vid.
> VID 0 was recently only added by the latter ones. So if driver only
> depended on dev->vlangrp, 0 was not there. This was changed recently by
> my "vlan cleanup" patches. It may work for you again on net-next today.
>
Hi there,
I'm finding it on the following two NICs:
02:00.0 Ethernet controller: Attansic Technology Corp. L1 Gigabit
Ethernet Adapter (rev b0)
05:01.0 Network controller [0280]: Broadcom Corporation BCM4306
802.11b/g Wireless LAN Controller [14e4:4320] (rev 03)
and (on a different machine):
02:00.0 Network controller [0280]: Intel Corporation WiFi Link 6000
Series [8086:422c] (rev 35)
The only one I have had any success with is:
00:19.0 Ethernet controller [0200]: Intel Corporation 82577LM Gigabit
Network Connection [8086:10ea] (rev 05)
Which I assume is because it has actual hardware acceleration. I may be
able to put net-next on the Intel Wifi box for testing at some point,
but I don't know how soon I'll be able to do that. Please let me know
whether that would be a worthwhile test, and if so I'll try and get it
done. Thanks...
Mike 5:)
^ permalink raw reply
* Re: Influencing triggering of xfrm acquire messages?
From: David Martin @ 2011-08-17 10:21 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20110811.073645.142128983331087817.davem@davemloft.net>
Hi,
On Thu, Aug 11, 2011 at 4:36 PM, David Miller <davem@davemloft.net> wrote:
> From: David Martin <david.martin.mailbox@googlemail.com>
> Date: Thu, 11 Aug 2011 16:21:07 +0200
>
>> As long as it exists no additional acquire will be triggered which is a problem,
>> for example when shortly after an exchange the daemon is restarted and needs to
>> start another exchange with the same peer host.
>>
>> Is this state supposed to be set up? Is it supposed to be removed automatically
>> once we set up our own SA? Is there a way to remove it manually to
>> trigger another acquire? Any input is welcome, thanks a lot in advance.
>
> The usage model is that the IPSEC daemon, like a routing daemon, manages
> all IPSEC state. And therefore it flushes all IPSEC state when it starts
> up.
>
> If you want the acquire messages, you need to flush the entries for which
> you want the acquire to trigger when you startup.
thanks for your reply, that sounds reasonable. The problem is this
specific state I
mentioned (see below).
> martin@pisa1:~$ sudo ip xfrm state
> src 2001:1a:a148:104c:92bb:671e:8100:9354 dst 2001:1c:5000:45b6:2d33:2c10:2726:a043
> proto 0 reqid 0 mode transport
> replay-window 0
> sel src 2001:1a:a148:104c:92bb:671e:8100:9354/128 dst 2001:1c:5000:45b6:2d33:2c10:2726:a043/128 proto udp sport 49024 dport 1025
It is not set up explicitly by us but on its own when the acquire is triggered.
We already take care of "our" states and flush them on exit / startup so that
they do not prohibit another acquire. This one though remains for a certain
time and the question is: how can I remove it? Which parameters do I need
to pass to the xfrm interface to flush it?
It does not seem to be possible with the iproute2 implementation
('ip xfrm state delete ...') as it requires a protocol in
{esp | ah | comp | route2 | hao} to delete a state. proto 0 as it is here is not
supported and refused as invalid. I have tried to adapt our code and send
a delete request with protocol, spi and ports set to 0 but this does not have
the desired effect.
Any idea how to tackle this?
David
^ permalink raw reply
* Re: [Bugme-new] [Bug 41152] New: kernel 3.0 and above fails to handle vlan id 0 (802.1p) packets properly without hardware acceleration
From: Jiri Pirko @ 2011-08-17 10:59 UTC (permalink / raw)
To: Mike Auty; +Cc: Andrew Morton, bugme-daemon, netdev
In-Reply-To: <4E4B615F.8060403@gmail.com>
Wed, Aug 17, 2011 at 08:36:15AM CEST, mike.auty@gmail.com wrote:
>On 17/08/11 06:37, Jiri Pirko wrote:
>>
>> Hi Mike. May I ask what NIC are you seeing the regression on?
>> It may have something to do with dev->vlangrp and ndo_vlan_add/kill_vid.
>> VID 0 was recently only added by the latter ones. So if driver only
>> depended on dev->vlangrp, 0 was not there. This was changed recently by
>> my "vlan cleanup" patches. It may work for you again on net-next today.
>>
>
>Hi there,
>
>I'm finding it on the following two NICs:
>
>02:00.0 Ethernet controller: Attansic Technology Corp. L1 Gigabit
>Ethernet Adapter (rev b0)
>
>05:01.0 Network controller [0280]: Broadcom Corporation BCM4306
>802.11b/g Wireless LAN Controller [14e4:4320] (rev 03)
>
>and (on a different machine):
>
>02:00.0 Network controller [0280]: Intel Corporation WiFi Link 6000
>Series [8086:422c] (rev 35)
I just obtained very similar card (8086:422b). Going to look at it right
away.
One more thing. What do you use to generate vlan0 tagged packets? I'm
using pktgen with "vlan_id 0". Would you please try that it behaves the
same for you?
>
>The only one I have had any success with is:
>
>00:19.0 Ethernet controller [0200]: Intel Corporation 82577LM Gigabit
>Network Connection [8086:10ea] (rev 05)
>
>Which I assume is because it has actual hardware acceleration. I may be
>able to put net-next on the Intel Wifi box for testing at some point,
>but I don't know how soon I'll be able to do that. Please let me know
>whether that would be a worthwhile test, and if so I'll try and get it
>done. Thanks...
>
>Mike 5:)
>
^ permalink raw reply
* Re: [net-next RFC PATCH 7/7] virtio-net changes
From: WANG Cong @ 2011-08-17 13:24 UTC (permalink / raw)
To: netdev; +Cc: qemu-devel, linux-kernel, kvm
In-Reply-To: <20110812015551.31613.13885.stgit@intel-e5620-16-2.englab.nay.redhat.com>
On Fri, 12 Aug 2011 09:55:51 +0800, Jason Wang wrote:
> From: Krishna Kumar <krkumar2@in.ibm.com>
>
> Implement mq virtio-net driver.
>
> Though struct virtio_net_config changes, it works with the old qemu
> since the last element is not accessed unless qemu sets
> VIRTIO_NET_F_MULTIQUEUE.
>
...
> +
> +#if 1
<...>
> +#else
<...>
> +#endif
Any reason to keep this #else code of #if 1? which is dead.
^ permalink raw reply
* Re: [PATCH V2 net-next 1/3] bnx2x: Remove local defines for %pM and mac address
From: Eilon Greenstein @ 2011-08-17 13:42 UTC (permalink / raw)
To: Joe Perches; +Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <194d8f8008a965d68812738f7530e07856952d3a.1313360100.git.joe@perches.com>
On Sun, 2011-08-14 at 15:16 -0700, Joe Perches wrote:
> Use %pM and mac address directly instead.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: Eilon Greenstein <eilong@broadcom.com>
^ permalink raw reply
* Re: [PATCH V2 net-next 0/3] bnx2x: Message logging cleanups
From: Eilon Greenstein @ 2011-08-17 13:42 UTC (permalink / raw)
To: Joe Perches; +Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <cover.1313360100.git.joe@perches.com>
On Sun, 2011-08-14 at 15:16 -0700, Joe Perches wrote:
> Joe Perches (3):
> bnx2x: Remove local defines for %pM and mac address
> bnx2x: Coalesce pr_cont uses and fix DP typos
> bnx2x: Use pr_fmt and message logging cleanups
>
> drivers/net/ethernet/broadcom/bnx2x/bnx2x.h | 67 ++++-----
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 48 ++++---
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h | 4 +-
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c | 5 +-
> .../net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c | 23 ++--
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c | 153 ++++++++++----------
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 72 ++++-----
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c | 67 ++++-----
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c | 46 +++---
> 9 files changed, 244 insertions(+), 241 deletions(-)
>
Thanks Joe, sorry it took a while - but ACK for all :)
Eilon
^ permalink raw reply
* Re: [PATCH V2 net-next 2/3] bnx2x: Coalesce pr_cont uses and fix DP typos
From: Eilon Greenstein @ 2011-08-17 13:42 UTC (permalink / raw)
To: Joe Perches; +Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <88e0b7cd0aa9fdb34acae665d8bc235f8aa33ddf.1313360100.git.joe@perches.com>
On Sun, 2011-08-14 at 15:16 -0700, Joe Perches wrote:
> Uses of pr_cont should be avoided where reasonably possible
> because they can be interleaved by other threads and processes.
>
> Coalesce pr_cont uses.
>
> Fix typos, duplicated words and spacing in DP uses caused
> by split multi-line formats. Coalesce some of these
> split formats. Add missing terminating newlines to DP uses.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: Eilon Greenstein <eilong@broadcom.com>
^ permalink raw reply
* Re: [PATCH V2 net-next 3/3] bnx2x: Use pr_fmt and message logging cleanups
From: Eilon Greenstein @ 2011-08-17 13:42 UTC (permalink / raw)
To: Joe Perches; +Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <2d33739418a06602c817d002b30fedd57cbe5f11.1313360101.git.joe@perches.com>
On Sun, 2011-08-14 at 15:16 -0700, Joe Perches wrote:
> Add pr_fmt(fmt) KBUILD_MODNAME ": " to prefix messages with "bnx2x: ".
> Remove #define DP_LEVEL and use pr_notice.
> Repeating KERN_<LEVEL> isn't necessary in multi-line printks.
> printk macro neatening, use fmt and ##__VA_ARGS__.
> Coalesce long formats.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: Eilon Greenstein <eilong@broadcom.com>
^ permalink raw reply
* Re: [PATCH 0/2] pktgen: Clone skb to avoid corruption of skbs in ndo_start_xmit methods (v3)
From: Ben Hutchings @ 2011-08-17 15:07 UTC (permalink / raw)
To: Neil Horman; +Cc: netdev
In-Reply-To: <1311696338-4739-1-git-send-email-nhorman@tuxdriver.com>
On Tue, 2011-07-26 at 12:05 -0400, Neil Horman wrote:
> Ok, after considering all your comments, Dave suggested this as an alternate
> approach:
>
> 1) We create a new priv_flag, IFF_SKB_TX_SHARED, to identify drivers capable of
> handling shared skbs. Default is to not set this flag
>
> 2) Modify ether_setup to enable this flag, under the assumption that any driver
> calling this function is initalizing a real ethernet device and as such can
> handle shared skbs since they don't tend to store state in the skb struct.
> Pktgen can then query this flag when a user script attempts to issue the
> clone_skb command and decide if it is to be alowed or not.
[...]
A bunch of Ethernet drivers do skb_pad() or skb_padto() in their
ndo_start_xmit implementations, either to avoid hardware bugs or because
the MAC doesn't automatically pad to the minimum frame length. This
presumably means they can't generally handle shared skbs, though in the
specific case of pktgen it should be safe as long as a single skb is not
submitted by multiple threads at once.
Ben.
--
Ben Hutchings, Staff 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
* [PATCH] bnx2x: downgrade Max BW error message to debug
From: Michal Schmidt @ 2011-08-17 15:50 UTC (permalink / raw)
To: eilong; +Cc: netdev@vger.kernel.org, Dmitry Kravkov, Vladislav Zolotarov
In-Reply-To: <1313498708.24298.0.camel@lb-tlvb-eilong.il.broadcom.com>
There are valid configurations where Max BW is configured to zero for
some VNs.
Print the message only if debugging is enabled and do not call the
configuration "illegal".
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h
index 223bfee..8245e02 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h
@@ -1481,8 +1481,7 @@ static inline u16 bnx2x_extract_max_cfg(struct bnx2x *bp, u32 mf_cfg)
u16 max_cfg = (mf_cfg & FUNC_MF_CFG_MAX_BW_MASK) >>
FUNC_MF_CFG_MAX_BW_SHIFT;
if (!max_cfg) {
- BNX2X_ERR("Illegal configuration detected for Max BW - "
- "using 100 instead\n");
+ BNX2X_DBG_ERR("Max BW configured to 0 - using 100 instead\n");
max_cfg = 100;
}
return max_cfg;
--
1.7.6
^ permalink raw reply related
* Linux vs FreeBSD Which is correct.
From: Stephen Clark @ 2011-08-17 17:03 UTC (permalink / raw)
To: Linux Kernel Network Developers
Hello List,
Firstly thank you for your patience. I am replacing a bunch of FreeBSD
vpn/fw/routers
with a Linux based system.
I have run into a situation where if I ping our HQ the response comes
back on a different
interface than what the request went out on. FreeBSD is happy and says
it got the response,
Linux is not and gives no indication it got a response.
So is FreeBSD wrong or is Linux wrong?
Or is there some sysctl I can fiddle with on Linux to make it see the
response. This happens
with the iptables set to accept on all chains.
Thanks again for your indulgence. I googled this and didn't find
anything germane.
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
^ permalink raw reply
* Re: Linux vs FreeBSD Which is correct.
From: Emil S Tantilov @ 2011-08-17 17:10 UTC (permalink / raw)
To: sclark46; +Cc: Linux Kernel Network Developers
In-Reply-To: <4E4BF456.9000807@earthlink.net>
On Wed, Aug 17, 2011 at 10:03 AM, Stephen Clark <sclark46@earthlink.net> wrote:
> Hello List,
>
> Firstly thank you for your patience. I am replacing a bunch of FreeBSD
> vpn/fw/routers
> with a Linux based system.
>
> I have run into a situation where if I ping our HQ the response comes back
> on a different
> interface than what the request went out on. FreeBSD is happy and says it
> got the response,
> Linux is not and gives no indication it got a response.
Try enabling ARP filtering:
echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter
Thanks,
Emil
^ permalink raw reply
* Re: Linux vs FreeBSD Which is correct.
From: Rémi Denis-Courmont @ 2011-08-17 17:17 UTC (permalink / raw)
To: sclark46; +Cc: Linux Kernel Network Developers
In-Reply-To: <4E4BF456.9000807@earthlink.net>
Le mercredi 17 août 2011 20:03:18 Stephen Clark, vous avez écrit :
> I have run into a situation where if I ping our HQ the response comes
> back on a different
> interface than what the request went out on. FreeBSD is happy and says
> it got the response,
> Linux is not and gives no indication it got a response.
>
> So is FreeBSD wrong or is Linux wrong?
Most distributions enable reverse path filtering by default.
It can be disabled:
# echo -n 0 > /proc/sys/net/ipv4/conf/all/rp_filter
But you should probably fix the configuration instead (e.g. /etc/sysctl.conf).
--
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis
^ permalink raw reply
* Re: [PATCH] bnx2x: downgrade Max BW error message to debug
From: Eilon Greenstein @ 2011-08-17 17:44 UTC (permalink / raw)
To: Michal Schmidt
Cc: netdev@vger.kernel.org, Dmitry Kravkov, Vladislav Zolotarov
In-Reply-To: <20110817175037.2777724a@brian.englab.brq.redhat.com>
On Wed, 2011-08-17 at 08:50 -0700, Michal Schmidt wrote:
> There are valid configurations where Max BW is configured to zero for
> some VNs.
> Print the message only if debugging is enabled and do not call the
> configuration "illegal".
>
> Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
>
> ---
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h
> index 223bfee..8245e02 100644
> --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h
> +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h
> @@ -1481,8 +1481,7 @@ static inline u16 bnx2x_extract_max_cfg(struct bnx2x *bp, u32 mf_cfg)
> u16 max_cfg = (mf_cfg & FUNC_MF_CFG_MAX_BW_MASK) >>
> FUNC_MF_CFG_MAX_BW_SHIFT;
> if (!max_cfg) {
> - BNX2X_ERR("Illegal configuration detected for Max BW - "
> - "using 100 instead\n");
> + BNX2X_DBG_ERR("Max BW configured to 0 - using 100 instead\n");
I think that we should use DP instead of DBG_ERR. How about this one:
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h
index 223bfee..70dc7bc 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h
@@ -1481,8 +1481,7 @@ static inline u16 bnx2x_extract_max_cfg(struct bnx2x *bp, u32 mf_cfg)
u16 max_cfg = (mf_cfg & FUNC_MF_CFG_MAX_BW_MASK) >>
FUNC_MF_CFG_MAX_BW_SHIFT;
if (!max_cfg) {
- BNX2X_ERR("Illegal configuration detected for Max BW - "
- "using 100 instead\n");
+ DP(NETIF_MSG_LINK, "Max BW configured to 0 - using 100 instead\n");
max_cfg = 100;
}
return max_cfg;
Can you sing-off on somethign like this?
Thanks,
Eilon
^ permalink raw reply related
* Re: [Bugme-new] [Bug 41152] New: kernel 3.0 and above fails to handle vlan id 0 (802.1p) packets properly without hardware acceleration
From: Jiri Pirko @ 2011-08-17 17:50 UTC (permalink / raw)
To: Mike Auty; +Cc: Andrew Morton, bugme-daemon, netdev
In-Reply-To: <20110817105950.GA4259@minipsycho.brq.redhat.com>
Wed, Aug 17, 2011 at 12:59:51PM CEST, jpirko@redhat.com wrote:
>Wed, Aug 17, 2011 at 08:36:15AM CEST, mike.auty@gmail.com wrote:
>>On 17/08/11 06:37, Jiri Pirko wrote:
>>>
>>> Hi Mike. May I ask what NIC are you seeing the regression on?
>>> It may have something to do with dev->vlangrp and ndo_vlan_add/kill_vid.
>>> VID 0 was recently only added by the latter ones. So if driver only
>>> depended on dev->vlangrp, 0 was not there. This was changed recently by
>>> my "vlan cleanup" patches. It may work for you again on net-next today.
>>>
>>
>>Hi there,
>>
>>I'm finding it on the following two NICs:
>>
>>02:00.0 Ethernet controller: Attansic Technology Corp. L1 Gigabit
>>Ethernet Adapter (rev b0)
>>
>>05:01.0 Network controller [0280]: Broadcom Corporation BCM4306
>>802.11b/g Wireless LAN Controller [14e4:4320] (rev 03)
>>
>>and (on a different machine):
>>
>>02:00.0 Network controller [0280]: Intel Corporation WiFi Link 6000
>>Series [8086:422c] (rev 35)
>
>I just obtained very similar card (8086:422b). Going to look at it right
>away.
>
>One more thing. What do you use to generate vlan0 tagged packets? I'm
>using pktgen with "vlan_id 0". Would you please try that it behaves the
>same for you?
I'm using following pktgen script:
http://pastebin.com/E3f4R8XY
On rx site with Intel wireless card I use following stap script to
observe incoming packets:
http://pastebin.com/VeXLhauu
All is looking good there. What do you use to look at incoming packets?
Jirka
>
>>
>>The only one I have had any success with is:
>>
>>00:19.0 Ethernet controller [0200]: Intel Corporation 82577LM Gigabit
>>Network Connection [8086:10ea] (rev 05)
>>
>>Which I assume is because it has actual hardware acceleration. I may be
>>able to put net-next on the Intel Wifi box for testing at some point,
>>but I don't know how soon I'll be able to do that. Please let me know
>>whether that would be a worthwhile test, and if so I'll try and get it
>>done. Thanks...
>>
>>Mike 5:)
>>
^ permalink raw reply
* Re: Linux vs FreeBSD Which is correct.
From: Stephen Clark @ 2011-08-17 17:20 UTC (permalink / raw)
To: Emil S Tantilov; +Cc: Linux Kernel Network Developers
In-Reply-To: <CANh3MnZnyuvdiMyQTKKN=v-+y98FGbu+zA+=D4VnFL41AgRHpw@mail.gmail.com>
On 08/17/2011 01:10 PM, Emil S Tantilov wrote:
> On Wed, Aug 17, 2011 at 10:03 AM, Stephen Clark<sclark46@earthlink.net> wrote:
>
>> Hello List,
>>
>> Firstly thank you for your patience. I am replacing a bunch of FreeBSD
>> vpn/fw/routers
>> with a Linux based system.
>>
>> I have run into a situation where if I ping our HQ the response comes back
>> on a different
>> interface than what the request went out on. FreeBSD is happy and says it
>> got the response,
>> Linux is not and gives no indication it got a response.
>>
> Try enabling ARP filtering:
> echo 1> /proc/sys/net/ipv4/conf/all/arp_filter
Just tried it - made no difference.
Thanks.
[root@L101111 ~]# echo 1 > /proc/sys/net/ipv4/conf/all/arp_filterL101111:~
$ ping -I 172.21.76.150 172.21.232.55
PING 172.21.232.55 (172.21.232.55) from 172.21.76.150 : 56(84) bytes of
data.
^C
--- 172.21.232.55 ping statistics ---
9 packets transmitted, 0 received, 100% packet loss, time 8238ms
L101111:~
$ sudo tcpdump -nli eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
13:19:13.808262 IP 172.21.232.55 > 172.21.76.150: ICMP echo reply, id
19545, seq 6, length 64
13:19:14.807541 IP 172.21.232.55 > 172.21.76.150: ICMP echo reply, id
19545, seq 7, length 64
^C
^ permalink raw reply
* Re: Transfer Offer
From: Song Li @ 2011-08-18 8:26 UTC (permalink / raw)
To: Recipients
l am a Staff of Hang Seng Bank HongKong, I do not know if we can work
together in transferring $19,500,000.USD from my bank to you account.
Finally if you are interested I shall provide you with more details.
Email: mr_song150@yahoo.com.hk
^ permalink raw reply
* Re: Linux vs FreeBSD Which is correct.
From: Stephen Clark @ 2011-08-17 19:44 UTC (permalink / raw)
To: Rémi Denis-Courmont; +Cc: Linux Kernel Network Developers
In-Reply-To: <201108172017.48683.remi@remlab.net>
On 08/17/2011 01:17 PM, Rémi Denis-Courmont wrote:
> Le mercredi 17 août 2011 20:03:18 Stephen Clark, vous avez écrit :
>
>> I have run into a situation where if I ping our HQ the response comes
>> back on a different
>> interface than what the request went out on. FreeBSD is happy and says
>> it got the response,
>> Linux is not and gives no indication it got a response.
>>
>> So is FreeBSD wrong or is Linux wrong?
>>
> Most distributions enable reverse path filtering by default.
> It can be disabled:
> # echo -n 0> /proc/sys/net/ipv4/conf/all/rp_filter
>
> But you should probably fix the configuration instead (e.g. /etc/sysctl.conf).
>
>
Sorry that didn't help either.
--
"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety." (Ben Franklin)
"The course of history shows that as a government grows, liberty
decreases." (Thomas Jefferson)
^ permalink raw reply
* Re: Linux vs FreeBSD Which is correct.
From: Pascal Hambourg @ 2011-08-17 20:15 UTC (permalink / raw)
To: sclark46; +Cc: Rémi Denis-Courmont, Linux Kernel Network Developers
In-Reply-To: <4E4C1A00.80207@earthlink.net>
Hello,
Stephen Clark a écrit :
> On 08/17/2011 01:17 PM, Rémi Denis-Courmont wrote:
>> Le mercredi 17 août 2011 20:03:18 Stephen Clark, vous avez écrit :
>>
>>> I have run into a situation where if I ping our HQ the response comes
>>> back on a different
>>> interface than what the request went out on. FreeBSD is happy and says
>>> it got the response,
>>> Linux is not and gives no indication it got a response.
>>>
>>> So is FreeBSD wrong or is Linux wrong?
Neither is right or wrong. It partly depends whether you want to enforce
so-called "weak" or "strong" host model.
>> Most distributions enable reverse path filtering by default.
>> It can be disabled:
>> # echo -n 0> /proc/sys/net/ipv4/conf/all/rp_filter
>>
>> But you should probably fix the configuration instead (e.g. /etc/sysctl.conf).
>>
> Sorry that didn't help either.
Since some kernel version the logic of this sysctl has changed from
AND(all, $interface) to MAX(all, $interface). So you must set
net/ipv4/conf/$interface/rp_filter to 0 too to disable it.
Or set net/ipv4/conf/all/rp_filter to 2 to make it weaker.
^ permalink raw reply
* Re: [Bugme-new] [Bug 41312] New: Regression: some web services (e.g. Dropbox, Amazon Cloud Reader) stops working in 3.1-rc2
From: Andrew Morton @ 2011-08-17 20:41 UTC (permalink / raw)
To: netdev; +Cc: bugme-daemon, salimma
In-Reply-To: <bug-41312-10286@https.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Wed, 17 Aug 2011 20:17:05 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=41312
>
> Summary: Regression: some web services (e.g. Dropbox, Amazon
> Cloud Reader) stops working in 3.1-rc2
> Product: Networking
> Version: 2.5
> Kernel Version: 3.1-rc2
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: IPV4
> AssignedTo: shemminger@linux-foundation.org
> ReportedBy: salimma@fedoraproject.org
> Regression: Yes
>
>
> Created an attachment (id=69102)
> --> (https://bugzilla.kernel.org/attachment.cgi?id=69102)
> (working) config for kernel 3.0
>
> Dropbox and Amazon Cloud Reader works just fine on kernel 3.0, but the former
> does not work on 3.1-rc1 and 3.1-rc2, and the latter does not work on 3.1-rc2
> (I no longer have a copy of the 3.1-rc1 build I did).
>
> With Dropbox, ps reports that the daemon process is in an uninterruptible
> state, and it cannot be killed (even with kill -9). Setting SELinux to
> permissive does not affect things (and Dropbox works with SELinux set to
> enforcing with kernel 3.0).
>
> With Cloud Reader, on Chrome, it does not display any book -- I perpetually get
> the "refreshing" icon.
>
> Will attach kernel configurations (I keep the 3.0 and 3.1-rc2 configs as
> similar as possible, by using 'make oldconfig' on 3.0 with 3.1-rc2's .config.
>
> Reported on Dropbox's forum: http://forums.dropbox.com/topic.php?id=43140
>
^ permalink raw reply
* RE: [PATCH 04/14] bna: Add Multiple Tx Queue Support
From: Rasesh Mody @ 2011-08-17 21:24 UTC (permalink / raw)
To: John Fastabend
Cc: Ben Hutchings, davem@davemloft.net, netdev@vger.kernel.org,
Adapter Linux Open SRC Team, Gurunatha Karaje
In-Reply-To: <4E4B55FC.5070000@intel.com>
>From: John Fastabend [mailto:john.r.fastabend@intel.com]
>Sent: Tuesday, August 16, 2011 10:48 PM
>
>On 8/16/2011 7:14 PM, Rasesh Mody wrote:
>>> From: John Fastabend [mailto:john.r.fastabend@intel.com]
>>> Sent: Tuesday, August 16, 2011 5:18 PM
>>>
>>> On 8/16/2011 4:43 PM, Ben Hutchings wrote:
>>>> On Tue, 2011-08-16 at 16:32 -0700, Rasesh Mody wrote:
>>>>>> From: Ben Hutchings [mailto:bhutchings@solarflare.com]
>>>>>> Sent: Tuesday, August 16, 2011 2:49 PM
>>>>>>
>>>>>> On Tue, 2011-08-16 at 14:19 -0700, Rasesh Mody wrote:
>>>>>>> Change details:
>>>>>>> - Add macros bna_prio_allow, bna_default_nw_prio,
>bna_iscsi_prio,
>>>>>>> bna_is_iscsi_over_cee
>>>>>>> - Added support for multipe Tx queues with a separate iSCSI Tx
>>> queue
>>>>>> based
>>>>>>> on the default value of iSCSI port number. The feature is
>>> supported
>>>>>> based
>>>>>>> on the underlying hardware and enabled for DCB (CEE) mode
>only.
>>>>>>> - Allocate multiple TxQ resource in netdev
>>>>>>> - Implement bnad_tx_select_queue() which enables the correct
>>>>>> selection of
>>>>>>> TxQ Id (and tcb). This function is called either by the kernel
>>> to
>>>>>> channel
>>>>>>> packets to the right TxQ
>>>>>>> - bnad_tx_select_queue() returns priority, while only a few
>>> packets
>>>>>> during
>>>>>>> transition could have wrong priority, all will be associated
>>> with a
>>>>>> valid
>>>>>>> non-NULL tcb.
>>>>>>> - Implement bnad_iscsi_tcb_get() and BNAD_IS_ISCSI_PKT() for
>iSCSI
>>>>>> packet
>>>>>>> inspection and retrieval of tcb corresponding to the iSCSI
>>>>>> priority.
>>>>>>> - Construction of priority indirection table to be used by bnad
>to
>>>>>> direct
>>>>>>> packets into TxQs
>>>>>> [...]
>>>>>>
>>>>>> You probably should implement TX priority classes through the
>>>>>> ndo_setup_tc operation, not ndo_select_queue.
>>>>>
>>>>> The reason we went with ndo_select_queue is due to the need for
>>> mapping
>>>>> iSCSI packets (TCP port 3260) to a priority derived from DCB
>>> configuration.
>>>>> Here the iSCSI packets may not have any tc defined in the packet
>>> header.
>>>>
>>>> There is an skb priority, which is derived from the socket priority
>>>> option (SO_PRIORITY). If you implement ndo_setup_tc then the
>>> networking
>>>> core will take care of mapping the skb priority onto a different
>queue
>>>> (or range of queues).
>>>>
>>>> I don't know whether the socket priority option is easily
>configurable
>>>> for the existing iSCSI implementations. But looking at port numbers
>>>> really doesn't seem like the right way to do this.
>>>>
>>>> Ben.
>>>>
>>>
>>> At least open-iscsi supports DCB by listening to the RTNLGRP_DCB for
>>> events.
>>> These are generated with dcbnl_cee_notify and dcbnl_ieee_notify. To
>>> support
>>> this in your driver you need to call dcb_setapp() or
>dcb_ieee_setapp()
>>> to
>>> add the application data and follow this with the appropriate notify
>>> call.
>>> Then assuming you do the necessary tc setup work the stack will
>handle
>>> the
>>> mapping of priority to queues.
>>
>> This is how iSCSI over DCB feature is expected to works in BNA
>driver:-
>> FW running in the BNA adapter implements the DCB protocol. It learns
>the
>> iSCSI priority from the switch through iSCSI TLV exchange. BNA driver
>> extracts the iSCSI priority from the FW that needs to be used for
>iSCSI
>> packets.
>
>Up to here this is fine. What I was suggesting was to then use the
>dcb_setapp() routines to program the iSCSI TLV and generate an event
>so any user space applications listening to DCB events could handle
>this. It would also be nice if your driver notified user space of
>any PG or PFC changes as well. Then management agents (lldpad) could
>use the DCB attributes to make policy decisions.
>
>> For every outgoing packet, BNA driver does a TCP header
>> inspection to classify iSCSI packet and attach right 802.1q priority &
>> send it on the correct TX queue.
>>
>> This is expected to work with iSCSI applications that do not configure
>the
>> priority with SO_PRIORITY - here the iSCSI priority configuration
>actually
>> comes from the switch to the adapter.
>>
>
>Although this works I don't think it is optimal for a few reason. Your
>L2 driver is inspecting TCP frames which is bad layering IMHO. The
>iSCSI port number is hard coded into the driver so it will only work
>with the well known port number. Also it adds more driver specific
>behavior into select_queue() where I think the trend is to try to
>use select_queue() less not more.
>
>To address iSCSI applications that do not configure the priority
>we could either work on adding the DCB hooks needed in those
>applications. Or look at adding a hook in the qdisc layer to
>to do what your select_queue() hook does here. I started prototyping
>this awhile ago but this requires running the packet classifiers
>and associated actions before picking a queue assuming you want
>to use mq or mqprio. I hope to get back to this soon I have some
>more details to flush out wrt this and need to run it by some other
>folks to make sure its a sane idea.
>
>
>> The goal of this iSCSI priority is:
>> a) adapter applies prioritized scheduling for packets in its egress -
>to
>> guarantee minimum bandwidth as per ETS
>> b) packets are tagged with right priority so that switch can also
>identify
>> and guarantee BW on its egress.
>
>Correct. This is the same for other drivers that support DCB and
>use tc_setup as Ben suggested. See the bnx2x driver for an example
>that also uses a FW based LLDP engine and does this.
>
>>
>> Hope this explains.
>
>I think the one valid item is the unsupported applications but
>hopefully that can be addressed. Thanks for the details.
Can we go with this approach of select_queue() for now till we have DCB hooks added to the iSCSI applications or the qdisc layer? We will address this to use setup_tc() as the framework becomes available.
Thanks,
Rasesh
^ permalink raw reply
* Re: Transfer Offer
From: Song Li @ 2011-08-18 10:37 UTC (permalink / raw)
To: Recipients
l am a Staff of Hang Seng Bank HongKong, I do not know if we can work
together in transferring $19,500,000.USD from my bank to you account.
Finally if you are interested I shall provide you with more details.
Email: mr_song150@yahoo.com.hk
^ permalink raw reply
* Re: Transfer Offer
From: Song Li @ 2011-08-18 11:33 UTC (permalink / raw)
To: Recipients
l am a Staff of Hang Seng Bank HongKong, I do not know if we can work
together in transferring $19,500,000.USD from my bank to you account.
Finally if you are interested I shall provide you with more details.
Email: mr_song150@yahoo.com.hk
^ permalink raw reply
* Re: [PATCH V2 net-next 0/3] bnx2x: Message logging cleanups
From: David Miller @ 2011-08-17 22:47 UTC (permalink / raw)
To: eilong; +Cc: joe, netdev, linux-kernel
In-Reply-To: <1313588528.7266.6.camel@lb-tlvb-eilong.il.broadcom.com>
From: "Eilon Greenstein" <eilong@broadcom.com>
Date: Wed, 17 Aug 2011 16:42:08 +0300
> On Sun, 2011-08-14 at 15:16 -0700, Joe Perches wrote:
>> Joe Perches (3):
>> bnx2x: Remove local defines for %pM and mac address
>> bnx2x: Coalesce pr_cont uses and fix DP typos
>> bnx2x: Use pr_fmt and message logging cleanups
>>
>> drivers/net/ethernet/broadcom/bnx2x/bnx2x.h | 67 ++++-----
>> drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 48 ++++---
>> drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h | 4 +-
>> drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c | 5 +-
>> .../net/ethernet/broadcom/bnx2x/bnx2x_ethtool.c | 23 ++--
>> drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c | 153 ++++++++++----------
>> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 72 ++++-----
>> drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c | 67 ++++-----
>> drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c | 46 +++---
>> 9 files changed, 244 insertions(+), 241 deletions(-)
>>
>
> Thanks Joe, sorry it took a while - but ACK for all :)
All applied, thanks everyone.
^ 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