* Re: [RFC patch net-next-2.6] net: convert bonding to use rx_handler
From: Jiri Pirko @ 2011-02-17 13:49 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, davem, shemminger, kaber, fubar, nicolas.2p.debian, andy
In-Reply-To: <1297948835.2604.50.camel@edumazet-laptop>
Thu, Feb 17, 2011 at 02:20:35PM CET, eric.dumazet@gmail.com wrote:
>Le jeudi 17 février 2011 à 13:52 +0100, Jiri Pirko a écrit :
>> Hello.
>>
>> This is an attempt to convert bonding to use rx_handler. Result should be
>> cleaner __netif_receive_skb() with much less exceptions needed. I think I
>> covered all aspects, not sure though. I gave this quick smoke test on my
>> testing env. Please comment, test.
>>
>> Thanks!
>>
>> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
>> ---
>> drivers/net/bonding/bond_main.c | 75 ++++++++++++++++++++-
>> include/linux/skbuff.h | 1 +
>> net/core/dev.c | 144 +++++++++++---------------------------
>> 3 files changed, 117 insertions(+), 103 deletions(-)
>>
>> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>
>
>> +
>> +static struct sk_buff *bond_handle_frame(struct sk_buff *skb)
>> +{
>> + struct net_device *slave_dev;
>> + struct net_device *bond_dev;
>> +
>> + skb = skb_share_check(skb, GFP_ATOMIC);
>> + if (unlikely(!skb))
>> + return NULL;
>> + slave_dev = skb->dev;
>> + bond_dev = slave_dev->master;
>
>I suggest being 10%% safe here :
>
> bond_dev = ACCESS_ONCE(slave_dev->master);
Right, will change this.
>
>> + if (unlikely(!bond_dev))
>> + return skb;
>> +
>> + if (bond_dev->priv_flags & IFF_MASTER_ARPMON)
>> + slave_dev->last_rx = jiffies;
>> +
>> + if (bond_should_deliver_exact_match(skb, slave_dev, bond_dev)) {
>> + skb->deliver_no_wcard = 1;
>> + return skb;
>> + }
>> +
>> + skb->dev = bond_dev;
>> +
>> + if (bond_dev->priv_flags & IFF_MASTER_ALB &&
>> + bond_dev->priv_flags & IFF_BRIDGE_PORT &&
>> + skb->pkt_type == PACKET_HOST) {
>> + u16 *dest = (u16 *) eth_hdr(skb)->h_dest;
>> +
>> + memcpy(dest, bond_dev->dev_addr, ETH_ALEN);
>> + }
>> +
>> + netif_rx(skb);
>> + return NULL;
>> +}
>> +
>
>
>> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
>> index 31f02d0..15b54ea 100644
>> --- a/include/linux/skbuff.h
>> +++ b/include/linux/skbuff.h
>> @@ -325,6 +325,7 @@ struct sk_buff {
>>
>> struct sock *sk;
>> struct net_device *dev;
>> + struct net_device *orig_dev;
>>
>> /*
>> * This is the control buffer. It is free to use for every
>
>Thats a problem. lifetime of this field is so small, I wonder if you
>cant find a solution to handle this differently. Maybe a percpu
>variable, or in cb[] ?
Yes, I was not feeling absolutely comfortable puting this here.
You mean global percpu variable living in net/core/dev.c? I must say I
would probably like skb->orig_dev more than that.
As for cb - I do not like that much. Also I think there might be
collision e.g. with bridge code.
>
>
>
^ permalink raw reply
* Question about tg3 and bnx2 driver suppliers
From: Michael Durket @ 2011-02-17 13:24 UTC (permalink / raw)
To: netdev
I'm trying to fix a problem with packet drops and frame errors (really rxbds_empty and rx_discards (or rx_fw_discards depending on whether or not its a tg3 supported chip or a bnx2 chip)). We have this happening on pretty much all the RedHat 5.x systems we're running these drivers on. In investigating what remedies to employ to fix this, I'm trying to determine if new versions of this driver are supplied by Broadcom, or by people within the Linux community so
I can find the right place to ask questions about it. I'm pretty sure this isn't the right list for these types of questions, but if someone could tell me whether I should be contacting Broadcom directly, or the name of some other Linux mailing list or forum that might help, I'd appreciate it.
^ permalink raw reply
* Re: Question about tg3 and bnx2 driver suppliers
From: Ben Hutchings @ 2011-02-17 14:16 UTC (permalink / raw)
To: Michael Durket; +Cc: netdev
In-Reply-To: <3BA51C2C-B28F-4FED-BF5D-B9BF46EAF3F7@highwire.stanford.edu>
On Thu, 2011-02-17 at 05:24 -0800, Michael Durket wrote:
> I'm trying to fix a problem with packet drops and frame errors (really
> rxbds_empty and rx_discards (or rx_fw_discards depending on whether or
> not its a tg3 supported chip or a bnx2 chip)). We have this happening
> on pretty much all the RedHat 5.x systems we're running these drivers
> on. In investigating what remedies to employ to fix this, I'm trying
> to determine if new versions of this driver are supplied by Broadcom,
> or by people within the Linux community so
> I can find the right place to ask questions about it. I'm pretty sure
> this isn't the right list for these types of questions, but if someone
> could tell me whether I should be contacting Broadcom directly, or the
> name of some other Linux mailing list or forum that might help, I'd
> appreciate it.
If you received the drivers as part of RHEL, you should ask Red Hat.
However, in general, RH takes drivers from Linus's tree - either as part
of a complete release, or as a backport. Most development on network
drivers for current production seems to be done by developers employed
or contracted by the corresponding manufacturers, but it is subject to
review by the Linux community as represented here on netdev.
The MAINTAINERS file in the Linux source tree lists the primary
maintainer(s) for each driver:
BROADCOM BNX2 GIGABIT ETHERNET DRIVER
M: Michael Chan <mchan@broadcom.com>
L: netdev@vger.kernel.org
S: Supported
F: drivers/net/bnx2.*
F: drivers/net/bnx2_*
BROADCOM TG3 GIGABIT ETHERNET DRIVER
M: Matt Carlson <mcarlson@broadcom.com>
M: Michael Chan <mchan@broadcom.com>
L: netdev@vger.kernel.org
S: Supported
F: drivers/net/tg3.*
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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: Question about tg3 and bnx2 driver suppliers
From: Eric Dumazet @ 2011-02-17 14:17 UTC (permalink / raw)
To: Michael Durket; +Cc: netdev
In-Reply-To: <3BA51C2C-B28F-4FED-BF5D-B9BF46EAF3F7@highwire.stanford.edu>
Le jeudi 17 février 2011 à 05:24 -0800, Michael Durket a écrit :
> I'm trying to fix a problem with packet drops and frame errors (really
> rxbds_empty and rx_discards (or rx_fw_discards depending on whether or
> not its a tg3 supported chip or a bnx2 chip)). We have this happening
> on pretty much all the RedHat 5.x systems we're running these drivers
> on. In investigating what remedies to employ to fix this, I'm trying
> to determine if new versions of this driver are supplied by Broadcom,
> or by people within the Linux community so
> I can find the right place to ask questions about it. I'm pretty sure
> this isn't the right list for these types of questions, but if someone
> could tell me whether I should be contacting Broadcom directly, or the
> name of some other Linux mailing list or forum that might help, I'd
> appreciate it.
>
It _is_ the right place, dont worry ;)
One possible cause of packet drops is when softirqs are disabled for too
long periods, even if NIC has a big RX ring (check ethtool -g eth0)
We fixed one big offender some weeks ago : iptables -L
Fix is in commit 83723d60717f8da0f53f
http://git2.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=83723d60717f8da0f53f91cf42a845ed56c09662
^ permalink raw reply
* biosdevname v0.3.7
From: Matt Domsch @ 2011-02-17 16:15 UTC (permalink / raw)
To: linux-hotplug, netdev, K, Narendra, Hargrave, Jordan,
Rose, Charles, Co
biosdevname, now version 0.3.7.
Major visible changes include no longer using '#' in device names (by
popular demand), no longer suggesting new names if running inside a VM
guest (tested with KVM, SLES 10 Xen, XenServer, VMware ESX, but it
uses the generic cpuid test, so should work on most virt platforms),
and a new kernel command line option 'biosdevname={0|1}' which udev
honors, to force enabling or disabling of invoking biosdevname.
Still to come: NPAR partition->port mapping support (initially
Dell-specific, but if NIC vendors have other ways to expose this,
please let me know).
Grab it here:
http://linux.dell.com/files/biosdevname/permalink/biosdevname-0.3.7.tar.gz
http://linux.dell.com/files/biosdevname/permalink/biosdevname-0.3.7.tar.gz.sign
git://linux.dell.com/biosdevname.git
I built this today for Fedora rawhide and F15, and I encourage
other distributions to pick it up as well.
shortlog:
Andrew Cooper (3):
Fix segfault when BIOS advertises zero sized PIRQ Routing Table
Add 'bonding' and 'openvswitch' to the virtual devices list
Typo fixes
Harald Hoyer (1):
Add kernel command line parameter "biosdevname={0|1}" to turn off/on
Matt Domsch (7):
don't build or package dump_pirq, use biosdecode from dmidecode instead
don't use '#' in names, use 'p' instead, by popular demand
properly look for SMBIOS, then $PIR, then recurse
update changelog
Fix test for PIRQ table version
fail PIRQ lookups if device domain is not 0
exit(4) if running a virtual machine
Thanks,
Matt
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
^ permalink raw reply
* Re: [PATCH 1/2] igb: Allow extra 4 bytes on RX for vlan tags.
From: Ben Greear @ 2011-02-17 17:28 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: netdev
In-Reply-To: <AANLkTinsWRAJ2bepa1NjQ4f0Wz46DaxWO6f_nEbmBAB0@mail.gmail.com>
On 02/17/2011 03:04 AM, Jeff Kirsher wrote:
> On Thu, Feb 10, 2011 at 13:59,<greearb@candelatech.com> wrote:
>> From: Ben Greear<greearb@candelatech.com>
>>
>> This allows the NIC to receive 1518 byte (not counting
>> FCS) packets when MTU is 1500, thus allowing 1500 MTU
>> VLAN frames to be received. Please note that no VLANs
>> were actually configured on the NIC...it was just acting
>> as pass-through device.
>>
>> Signed-off-by: Ben Greear<greearb@candelatech.com>
>> ---
>> :100644 100644 58c665b... 30c9cc6... M drivers/net/igb/igb_main.c
>> drivers/net/igb/igb_main.c | 5 +++--
>> 1 files changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/igb/igb_main.c b/drivers/net/igb/igb_main.c
>> index 58c665b..30c9cc6 100644
>> --- a/drivers/net/igb/igb_main.c
>> +++ b/drivers/net/igb/igb_main.c
>> @@ -2281,7 +2281,8 @@ static int __devinit igb_sw_init(struct igb_adapter *adapter)
>> adapter->rx_itr_setting = IGB_DEFAULT_ITR;
>> adapter->tx_itr_setting = IGB_DEFAULT_ITR;
>>
>> - adapter->max_frame_size = netdev->mtu + ETH_HLEN + ETH_FCS_LEN;
>> + adapter->max_frame_size = (netdev->mtu + ETH_HLEN + ETH_FCS_LEN
>> + + VLAN_HLEN);
>> adapter->min_frame_size = ETH_ZLEN + ETH_FCS_LEN;
>>
>> spin_lock_init(&adapter->stats64_lock);
>> @@ -4303,7 +4304,7 @@ static int igb_change_mtu(struct net_device *netdev, int new_mtu)
>> {
>> struct igb_adapter *adapter = netdev_priv(netdev);
>> struct pci_dev *pdev = adapter->pdev;
>> - int max_frame = new_mtu + ETH_HLEN + ETH_FCS_LEN;
>> + int max_frame = new_mtu + ETH_HLEN + ETH_FCS_LEN + VLAN_HLEN;
>> u32 rx_buffer_len, i;
>>
>> if ((new_mtu< 68) || (max_frame> MAX_JUMBO_FRAME_SIZE)) {
>
> While testing this patch, validation found that the patch reduces the
> maximum mtu size
> by 4 bytes (reduces it from 9216 to 9212). This is not a desired side
> effect of this patch.
You could add handling for that case and have it act as it used to when
new_mtu is greater than 9212?
I tested e1000e and it worked w/out hacking at 1500 MTU, so maybe
check how it does it?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: Read sent/received bytes -- without opening a file in /sys or /proc
From: Ben Greear @ 2011-02-17 17:32 UTC (permalink / raw)
To: Jan-Philip gehrcke; +Cc: netdev
In-Reply-To: <4D5CFF19.6050400@googlemail.com>
On 02/17/2011 02:57 AM, Jan-Philip gehrcke wrote:
> Dear list,
>
> I'm about to write a small C program for measurements of the bandwidth
> on some network interface of my home router (uname -a: Linux
> fritz.fonwlan.box 2.6.19.2 #2 Thu Nov 18 16:35:17 CET 2010 mips
> GNU/Linux). I would like to accomplish very *precise* results, while
> keeping the absolute measurement time low.
>
> In general, this problem requires the knowledge of time and byte
> differences. Therefore, two time measurements and two byte counter
> measurements for each, received and sent bytes, are required. Currently,
> I am measuring time via
>
> clock_gettime(CLOCK_MONOTONIC, ...)
>
> and reading the byte counters by reading files in sysfs, e.g.
>
> /sys/class/net/${interface}/statistics/rx_bytes.
>
> This is very easy and works well, but reading these files four times
> takes some (varying) time* on my device, which introduces an error to my
> calculation.
>
> Hence, I am wondering, if there is a way to receive this kind of data
> directly and much faster, via "kernel API". My question is related to
> this unanswered one from 2005:
> http://linux.derkeiler.com/Mailing-Lists/RedHat/2005-02/0557.html
>
> *On my device, reading such a file and interpreting the result as
> integer takes 1-10 ms, measured via:
>
> clock_gettime(CLOCK_MONOTONIC,&t_start);
> rx_bytes = read_int_from_file("/sys/class/net/wan/statistics/rx_bytes");
> clock_gettime(CLOCK_MONOTONIC,&t_end);
>
> read_int_from_file() basically consists of fopen(), fgets(), and sscanf().
>
>
> Please note that I don't have kernel/driver programming experience so far.
>
> Thank you for help and any suggestions!
>
> Jan-Philip Gehrcke
The netlink API can get stats for you, but I don't know if it would
be any more accurate time-wise. It's not exactly trivial to
implement this API, but you can look at the 'ip' program to get
an idea:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git
There is also /proc/net/dev, but that may be worse than using sysfs
as far as performance and time accuracy goes.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: Multicast snooping fixes and suggestions
From: Linus Lüssing @ 2011-02-17 18:17 UTC (permalink / raw)
To: Stephen Hemminger, David S. Miller, bridge
Cc: netdev, linux-kernel, Herbert Xu, YOSHIFUJI Hideaki
In-Reply-To: <20110215154128.2a28632c@nehalam>
> These look correct. Did you test them with real traffic?
Yes, I did. With these patches the hashlist and linked lists per port
are being filled correctly for IPv6 - initially. Verified that with
both some printk()s for the per port mglists as well as with vlc. With
patch 5/5 this also worked fine with transient link local addresses,
verified that with 'vlc -vvv "udp://@[ff12::123%eth1]"' on a device
connected to the other one with the bridge and could stream
a video as expected with no multicast traffic on any other bridge port.
However, the MLD queries are/were still broken, the queries initiated
by the bridge device do not get a response from the multicast listeners.
The following additional, attached patches fix this issue.
Last but not least, there are still a couple of bugs I could observe:
- I have attached a laptop with two interfaces with a multicast listener
each to another PC playing with the bridge device. With the fixes
below, the laptop sends a multicast listener report to the other PC
on each interface, however these reports' IPv6 header's source addresses
seem to be a random one from any of the laptop's two interfaces'
link local addresses (which has to be a bug in the IPv6 code, as
this one is generating the reports and not the bridge code) as long
as it matches the selected multicast address (which was ff12::123 in
this case).
- If there is no multicast listener present, then the multicast packets
get flooded on all bridge ports.
And two issues with a little lower priority, I suppose:
- Packets do not get delivered to the bridge interface itself when
a multicast listener has been started on this bridge interface
(might be related to http://www.spinics.net/lists/linux-net/msg17556.html,
so possibly a bug in the IPv6 code again).
~ Quitting of a multicast listener with a MLDv2 message is interpreted as
a join, resulting in relatively long timeouts - but this MLDv1
interpretation of MLDv2 messages seems to be intended so far due to its
simplicity according to the comment in the code.
Cheers, Linus
^ permalink raw reply
* [PATCH 1/2] bridge: Fix MLD queries' ethernet source address
From: Linus Lüssing @ 2011-02-17 18:17 UTC (permalink / raw)
To: Stephen Hemminger, David S. Miller, bridge
Cc: netdev, linux-kernel, Herbert Xu, YOSHIFUJI Hideaki,
Linus Lüssing
In-Reply-To: <20110215154128.2a28632c@nehalam>
Map the IPv6 header's destination multicast address to an ethernet
source address instead of the MLD queries multicast address.
For instance for a general MLD query (multicast address in the MLD query
set to ::), this would wrongly be mapped to 33:33:00:00:00:00, although
an MLD queries destination MAC should always be 33:33:00:00:00:01 which
matches the IPv6 header's multicast destination ff02::1.
Signed-off-by: Linus Lüssing <linus.luessing@web.de>
---
net/bridge/br_multicast.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index b5eb28a..f904a2e 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -435,7 +435,6 @@ static struct sk_buff *br_ip6_multicast_alloc_query(struct net_bridge *br,
eth = eth_hdr(skb);
memcpy(eth->h_source, br->dev->dev_addr, 6);
- ipv6_eth_mc_map(group, eth->h_dest);
eth->h_proto = htons(ETH_P_IPV6);
skb_put(skb, sizeof(*eth));
@@ -449,6 +448,7 @@ static struct sk_buff *br_ip6_multicast_alloc_query(struct net_bridge *br,
ip6h->hop_limit = 1;
ipv6_addr_set(&ip6h->saddr, 0, 0, 0, 0);
ipv6_addr_set(&ip6h->daddr, htonl(0xff020000), 0, 0, htonl(1));
+ ipv6_eth_mc_map(&ip6h->daddr, eth->h_dest);
hopopt = (u8 *)(ip6h + 1);
hopopt[0] = IPPROTO_ICMPV6; /* next hdr */
--
1.7.2.3
^ permalink raw reply related
* [PATCH 2/2] bridge: Use IPv6 link-local address for multicast listener queries
From: Linus Lüssing @ 2011-02-17 18:17 UTC (permalink / raw)
To: Stephen Hemminger, David S. Miller, bridge
Cc: netdev, linux-kernel, Herbert Xu, YOSHIFUJI Hideaki,
Linus Lüssing
In-Reply-To: <20110215154128.2a28632c@nehalam>
Currently the bridge multicast snooping feature periodically issues
IPv6 general multicast listener queries to sense the absence of a
listener.
For this, it uses :: as its source address - however RFC 2710 requires:
"To be valid, the Query message MUST come from a link-local IPv6 Source
Address". Current Linux kernel versions seem to follow this requirement
and ignore our bogus MLD queries.
With this commit a link local address from the bridge interface is being
used to issue the MLD query, resulting in other Linux devices which are
multicast listeners in the network to respond with a MLD response (which
was not the case before).
Signed-off-by: Linus Lüssing <linus.luessing@web.de>
---
net/bridge/br_multicast.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index f904a2e..2d88861 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -446,7 +446,8 @@ static struct sk_buff *br_ip6_multicast_alloc_query(struct net_bridge *br,
ip6h->payload_len = htons(8 + sizeof(*mldq));
ip6h->nexthdr = IPPROTO_HOPOPTS;
ip6h->hop_limit = 1;
- ipv6_addr_set(&ip6h->saddr, 0, 0, 0, 0);
+ ipv6_dev_get_saddr(dev_net(br->dev), br->dev, &ip6h->daddr, 0,
+ &ip6h->saddr);
ipv6_addr_set(&ip6h->daddr, htonl(0xff020000), 0, 0, htonl(1));
ipv6_eth_mc_map(&ip6h->daddr, eth->h_dest);
--
1.7.2.3
^ permalink raw reply related
* [net-next-2.6 PATCH 0/3] enic: updates to version 2.1.1.9
From: Vasanthy Kolluri @ 2011-02-17 18:53 UTC (permalink / raw)
To: davem; +Cc: netdev
The following series implements enic driver updates:
1/3 - Bug fix: Reset driver count of registered unicast addresses to zero during device reset
2/3 - Clean up: Remove a not needed #ifdef
3/3 - Always use single transmit and single receive hardware queues per device
Signed-off-by: Christian Benvenuti <benve@cisco.com>
Signed-off-by: Danny Guo <dannguo@cisco.com>
Signed-off-by: Vasanthy Kolluri <vkolluri@cisco.com>
Signed-off-by: Roopa Prabhu <roprabhu@cisco.com>
Signed-off-by: David Wang <dwang2@cisco.com>
^ permalink raw reply
* [net-next-2.6 PATCH 1/3] enic: Bug fix: Reset driver count of registered unicast addresses to zero during device reset
From: Vasanthy Kolluri @ 2011-02-17 18:53 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <20110217185245.2476.60944.stgit@savbu-pc100.cisco.com>
From: Vasanthy Kolluri <vkolluri@cisco.com>
During a device reset, clear the counter for the no. of unicast addresses registered.
Also, rename the routines that update unicast and multicast address lists.
Signed-off-by: Christian Benvenuti <benve@cisco.com>
Signed-off-by: Danny Guo <dannguo@cisco.com>
Signed-off-by: Vasanthy Kolluri <vkolluri@cisco.com>
Signed-off-by: Roopa Prabhu <roprabhu@cisco.com>
Signed-off-by: David Wang <dwang2@cisco.com>
---
drivers/net/enic/enic.h | 2 +-
drivers/net/enic/enic_main.c | 13 +++++++------
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/net/enic/enic.h b/drivers/net/enic/enic.h
index 57fcaee..5f4eb45 100644
--- a/drivers/net/enic/enic.h
+++ b/drivers/net/enic/enic.h
@@ -32,7 +32,7 @@
#define DRV_NAME "enic"
#define DRV_DESCRIPTION "Cisco VIC Ethernet NIC Driver"
-#define DRV_VERSION "2.1.1.6"
+#define DRV_VERSION "2.1.1.7"
#define DRV_COPYRIGHT "Copyright 2008-2011 Cisco Systems, Inc"
#define ENIC_BARS_MAX 6
diff --git a/drivers/net/enic/enic_main.c b/drivers/net/enic/enic_main.c
index 0c24370..a625a0e 100644
--- a/drivers/net/enic/enic_main.c
+++ b/drivers/net/enic/enic_main.c
@@ -874,9 +874,10 @@ static struct net_device_stats *enic_get_stats(struct net_device *netdev)
return net_stats;
}
-static void enic_reset_multicast_list(struct enic *enic)
+static void enic_reset_addr_lists(struct enic *enic)
{
enic->mc_count = 0;
+ enic->uc_count = 0;
enic->flags = 0;
}
@@ -941,7 +942,7 @@ static int enic_set_mac_address(struct net_device *netdev, void *p)
return enic_dev_add_station_addr(enic);
}
-static void enic_add_multicast_addr_list(struct enic *enic)
+static void enic_update_multicast_addr_list(struct enic *enic)
{
struct net_device *netdev = enic->netdev;
struct netdev_hw_addr *ha;
@@ -996,7 +997,7 @@ static void enic_add_multicast_addr_list(struct enic *enic)
enic->mc_count = mc_count;
}
-static void enic_add_unicast_addr_list(struct enic *enic)
+static void enic_update_unicast_addr_list(struct enic *enic)
{
struct net_device *netdev = enic->netdev;
struct netdev_hw_addr *ha;
@@ -1073,9 +1074,9 @@ static void enic_set_rx_mode(struct net_device *netdev)
}
if (!promisc) {
- enic_add_unicast_addr_list(enic);
+ enic_update_unicast_addr_list(enic);
if (!allmulti)
- enic_add_multicast_addr_list(enic);
+ enic_update_multicast_addr_list(enic);
}
}
@@ -2067,7 +2068,7 @@ static void enic_reset(struct work_struct *work)
enic_dev_hang_notify(enic);
enic_stop(enic->netdev);
enic_dev_hang_reset(enic);
- enic_reset_multicast_list(enic);
+ enic_reset_addr_lists(enic);
enic_init_vnic_resources(enic);
enic_set_rss_nic_cfg(enic);
enic_dev_set_ig_vlan_rewrite_mode(enic);
^ permalink raw reply related
* [net-next-2.6 PATCH 2/3] enic: Clean up: Remove a not needed #ifdef
From: Vasanthy Kolluri @ 2011-02-17 18:53 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <20110217185245.2476.60944.stgit@savbu-pc100.cisco.com>
From: Vasanthy Kolluri <vkolluri@cisco.com>
Signed-off-by: Christian Benvenuti <benve@cisco.com>
Signed-off-by: Danny Guo <dannguo@cisco.com>
Signed-off-by: Vasanthy Kolluri <vkolluri@cisco.com>
Signed-off-by: Roopa Prabhu <roprabhu@cisco.com>
Signed-off-by: David Wang <dwang2@cisco.com>
---
drivers/net/enic/enic.h | 2 +-
drivers/net/enic/enic_main.c | 2 --
2 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/net/enic/enic.h b/drivers/net/enic/enic.h
index 5f4eb45..2ac891b 100644
--- a/drivers/net/enic/enic.h
+++ b/drivers/net/enic/enic.h
@@ -32,7 +32,7 @@
#define DRV_NAME "enic"
#define DRV_DESCRIPTION "Cisco VIC Ethernet NIC Driver"
-#define DRV_VERSION "2.1.1.7"
+#define DRV_VERSION "2.1.1.8"
#define DRV_COPYRIGHT "Copyright 2008-2011 Cisco Systems, Inc"
#define ENIC_BARS_MAX 6
diff --git a/drivers/net/enic/enic_main.c b/drivers/net/enic/enic_main.c
index a625a0e..d1aa807 100644
--- a/drivers/net/enic/enic_main.c
+++ b/drivers/net/enic/enic_main.c
@@ -2223,9 +2223,7 @@ static const struct net_device_ops enic_netdev_dynamic_ops = {
.ndo_tx_timeout = enic_tx_timeout,
.ndo_set_vf_port = enic_set_vf_port,
.ndo_get_vf_port = enic_get_vf_port,
-#ifdef IFLA_VF_MAX
.ndo_set_vf_mac = enic_set_vf_mac,
-#endif
#ifdef CONFIG_NET_POLL_CONTROLLER
.ndo_poll_controller = enic_poll_controller,
#endif
^ permalink raw reply related
* [net-next-2.6 PATCH 3/3] enic: Always use single transmit and single receive hardware queues per device
From: Vasanthy Kolluri @ 2011-02-17 18:53 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <20110217185245.2476.60944.stgit@savbu-pc100.cisco.com>
From: Vasanthy Kolluri <vkolluri@cisco.com>
Signed-off-by: Christian Benvenuti <benve@cisco.com>
Signed-off-by: Danny Guo <dannguo@cisco.com>
Signed-off-by: Vasanthy Kolluri <vkolluri@cisco.com>
Signed-off-by: Roopa Prabhu <roprabhu@cisco.com>
Signed-off-by: David Wang <dwang2@cisco.com>
---
drivers/net/enic/enic.h | 6 +++---
drivers/net/enic/enic_main.c | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/enic/enic.h b/drivers/net/enic/enic.h
index 2ac891b..aee5256 100644
--- a/drivers/net/enic/enic.h
+++ b/drivers/net/enic/enic.h
@@ -32,13 +32,13 @@
#define DRV_NAME "enic"
#define DRV_DESCRIPTION "Cisco VIC Ethernet NIC Driver"
-#define DRV_VERSION "2.1.1.8"
+#define DRV_VERSION "2.1.1.9"
#define DRV_COPYRIGHT "Copyright 2008-2011 Cisco Systems, Inc"
#define ENIC_BARS_MAX 6
-#define ENIC_WQ_MAX 8
-#define ENIC_RQ_MAX 8
+#define ENIC_WQ_MAX 1
+#define ENIC_RQ_MAX 1
#define ENIC_CQ_MAX (ENIC_WQ_MAX + ENIC_RQ_MAX)
#define ENIC_INTR_MAX (ENIC_CQ_MAX + 2)
diff --git a/drivers/net/enic/enic_main.c b/drivers/net/enic/enic_main.c
index d1aa807..4f1710e 100644
--- a/drivers/net/enic/enic_main.c
+++ b/drivers/net/enic/enic_main.c
@@ -2080,7 +2080,7 @@ static void enic_reset(struct work_struct *work)
static int enic_set_intr_mode(struct enic *enic)
{
unsigned int n = min_t(unsigned int, enic->rq_count, ENIC_RQ_MAX);
- unsigned int m = 1;
+ unsigned int m = min_t(unsigned int, enic->wq_count, ENIC_WQ_MAX);
unsigned int i;
/* Set interrupt mode (INTx, MSI, MSI-X) depending
^ permalink raw reply related
* Re: any way to reset all marked connections when using CONNMARK?
From: Chris Friesen @ 2011-02-17 18:58 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Andrew Beverley, netdev, netfilter-devel, netfilter
In-Reply-To: <alpine.LNX.2.01.1102152342380.18599@obet.zrqbmnf.qr>
On 02/15/2011 04:42 PM, Jan Engelhardt wrote:
> On Tuesday 2011-02-15 23:06, Chris Friesen wrote:
>> For some reason the online man pages for conntrack don't seem to be up
>> to date...they don't have the -U option. It's listed in the package
>> itself though.
>
> What online manpages are you referring to?
The first google result for "man conntrack" is
http://linux.die.net/man/8/conntrack
which appears out of date. The second google result appears okay.
Chris
--
Chris Friesen
Software Developer
GENBAND
chris.friesen@genband.com
www.genband.com
^ permalink raw reply
* [PATCH ethtool] ethtool: Warn if we cannot set the advertising mask for specified speed/duplex
From: Ben Hutchings @ 2011-02-17 19:06 UTC (permalink / raw)
To: netdev; +Cc: linux-net-drivers, Naveen Chouksey
When autonegotiation is enabled, drivers must determine link speed and
duplex through the autonegotiation process and will generally ignore
the speed and duplex specified in struct ethtool_cmd. If the user
specifies a recognised combination of speed and duplex, we set the
advertising mask to include only the matching mode. Otherwise, we
advertise all supported modes. We should really limit the advertised
modes separately by speed and duplex, but for now we just warn.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
This is a longstanding bug in ethtool which people keep getting bitten
by. Naveen was just the latest to report it. I have been working on
some changes to improve link advertising and reporting, but until those
are ready I'm adding this warning.
Ben.
ethtool.c | 46 ++++++++++++++++++++++++++++++++--------------
1 files changed, 32 insertions(+), 14 deletions(-)
diff --git a/ethtool.c b/ethtool.c
index 1afdfe4..a5c70d5 100644
--- a/ethtool.c
+++ b/ethtool.c
@@ -1126,7 +1126,7 @@ static void parse_cmdline(int argc, char **argp)
}
}
- if ((autoneg_wanted == AUTONEG_ENABLE) && (advertising_wanted < 0)) {
+ if (advertising_wanted < 0) {
if (speed_wanted == SPEED_10 && duplex_wanted == DUPLEX_HALF)
advertising_wanted = ADVERTISED_10baseT_Half;
else if (speed_wanted == SPEED_10 &&
@@ -2528,19 +2528,37 @@ static int do_sset(int fd, struct ifreq *ifr)
ecmd.phy_address = phyad_wanted;
if (xcvr_wanted != -1)
ecmd.transceiver = xcvr_wanted;
- if (advertising_wanted != -1) {
- if (advertising_wanted == 0)
- ecmd.advertising = ecmd.supported &
- (ADVERTISED_10baseT_Half |
- ADVERTISED_10baseT_Full |
- ADVERTISED_100baseT_Half |
- ADVERTISED_100baseT_Full |
- ADVERTISED_1000baseT_Half |
- ADVERTISED_1000baseT_Full |
- ADVERTISED_2500baseX_Full |
- ADVERTISED_10000baseT_Full);
- else
- ecmd.advertising = advertising_wanted;
+ if (advertising_wanted == 0) {
+ /* XXX If autoneg is on and the user
+ * specified speed or duplex then we
+ * should mask the advertised modes
+ * accordingly. For now, warn that we
+ * aren't doing that.
+ */
+ if (ecmd.autoneg &&
+ (speed_wanted >= 0 || duplex_wanted >= 0)) {
+ fprintf(stderr, "Cannot advertise");
+ if (speed_wanted >= 0)
+ fprintf(stderr, " speed %d",
+ speed_wanted);
+ if (duplex_wanted >= 0)
+ fprintf(stderr, " duplex %s",
+ duplex_wanted ?
+ "full" : "half");
+ fprintf(stderr, "; advertising all"
+ " supported modes\n");
+ }
+ ecmd.advertising = ecmd.supported &
+ (ADVERTISED_10baseT_Half |
+ ADVERTISED_10baseT_Full |
+ ADVERTISED_100baseT_Half |
+ ADVERTISED_100baseT_Full |
+ ADVERTISED_1000baseT_Half |
+ ADVERTISED_1000baseT_Full |
+ ADVERTISED_2500baseX_Full |
+ ADVERTISED_10000baseT_Full);
+ } else if (advertising_wanted != -1) {
+ ecmd.advertising = advertising_wanted;
}
/* Try to perform the update. */
--
1.7.3.4
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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 related
* Re: [net-2.6 0/4][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2011-02-17 20:44 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips
In-Reply-To: <1297935310-23510-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 17 Feb 2011 01:35:06 -0800
> The following series contains two fixes for e1000e and ixgbe.
>
> The following are changes since commit 6d90e8f45697c633f522269368297d7416fd8783:
> isdn: hisax: Use l2headersize() instead of dup (and buggy) func.
>
> and are available in the git repository at:
> master.kernel.org:/pub/scm/linux/kernel/git/jkirsher/net-2.6 master
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH v2] bnx2x: Support for managing RX indirection table
From: David Miller @ 2011-02-17 20:49 UTC (permalink / raw)
To: eilong; +Cc: eric.dumazet, therbert, netdev
In-Reply-To: <1297947524.4722.2.camel@lb-tlvb-eilong.il.broadcom.com>
From: "Eilon Greenstein" <eilong@broadcom.com>
Date: Thu, 17 Feb 2011 14:58:44 +0200
> On Thu, 2011-02-17 at 01:09 -0800, Eric Dumazet wrote:
>> Le mercredi 16 février 2011 à 12:27 -0800, Tom Herbert a écrit :
>> > Support fetching and retrieving RX indirection table via ethtool.
>> >
>> > Signed-off-by: Tom Herbert <therbert@google.com>
>> > ---
>> > drivers/net/bnx2x/bnx2x.h | 2 +
>> > drivers/net/bnx2x/bnx2x_ethtool.c | 56 +++++++++++++++++++++++++++++++++++++
>> > drivers/net/bnx2x/bnx2x_main.c | 22 +++++++++++---
>> > 3 files changed, 75 insertions(+), 5 deletions(-)
>>
>> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> Acked-by: Eilon Greenstein <eilong@broadcom.com>
>
> Thanks everyone!
Applied to net-next-2.6, thanks!
^ permalink raw reply
* Re: [PATCH 1/1] tproxy: do not assign timewait sockets to skb->sk
From: Florian Westphal @ 2011-02-17 20:52 UTC (permalink / raw)
To: Balazs Scheidler
Cc: Florian Westphal, netfilter-devel, netdev, KOVACS Krisztian
In-Reply-To: <1297972902.2253.51.camel@Nokia-N900-51-1>
Balazs Scheidler <bazsi@balabit.hu> wrote:
> the only issue I see with this solution is that late packets will not be delivered to the proper socket, and will possibly be going to the fwd chain, which might be unexpected.
Why?
They'll get the proper nfmark, so they will be routed to the local
machine. The tcp stack should find the tw socket via normal sk lookup.
Or am i missing something?
^ permalink raw reply
* Re: [PATCH 1/1] tproxy: do not assign timewait sockets to skb->sk
From: Florian Westphal @ 2011-02-17 21:27 UTC (permalink / raw)
To: Balazs Scheidler
Cc: Florian Westphal, netfilter-devel, netdev, KOVACS Krisztian
In-Reply-To: <1297976642.3789.5.camel@Nokia-N900-51-1>
Balazs Scheidler <bazsi@balabit.hu> wrote:
> the destination port in the packet can be different in the two lookups. --on-port tproxy option.
Hrm... The initial lookup uses the header ip addresses:
sk = nf_tproxy_get_sock_v4(dev_net(skb->dev), iph->protocol,
iph->saddr, iph->daddr,
hp->source, hp->dest,
skb->dev, NFT_LOOKUP_ESTABLISHED);
3 possible cases:
- no socket -- try to find listener. This case is not changed by my patch.
- sk is normal socket. set nfmark and skb->sk. Also not changed.
- sk is in TW state. This is not changed either:
tproxy_handle_time_wait4() will check if this is a SYN. If it is, a new
listener lookup is made, and TW socket is kicked out.
If the packet is not a SYN, then tproxy_handle_time_wait4() won't do anything.
Previously, the timewait sk would now be assigned to skb->sk, which my patch
prevents. But I don't see where the '--on-port' port number is involved in the
TW socket lookup?
Thanks for reviwing the patch!
^ permalink raw reply
* RE: ixgbe: 82599 and Westmere with HT
From: Skidmore, Donald C @ 2011-02-17 22:06 UTC (permalink / raw)
To: Andrew Dickinson, netdev@vger.kernel.org
In-Reply-To: <AANLkTi=1d8aJoFU7gsNy-sYjJomGp-Xz4K+ddKSOk-ir@mail.gmail.com>
Hey Andrew,
Sorry about the slow reply I'm a bit backed up right now. :)
It sounds like you could be using using RSS hashing? It's limited to 16 indices. If you are using Flow Director hashing then maybe your flows aren't varying enough, although from your description it sounds as if they should be. What if you try something like 'netperf -t TCP_CRR'.
Let me know if any of my assumptions are incorrect.
Thanks,
-Don Skidmore <donald.c.skidmore@intel.com>
>-----Original Message-----
>From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
>On Behalf Of Andrew Dickinson
>Sent: Wednesday, February 16, 2011 5:22 PM
>To: netdev@vger.kernel.org
>Subject: ixgbe: 82599 and Westmere with HT
>
>Hi,
>
>I've got a dual Westmere board (X5675) with an X520 card with dual
>10G. I see 24-cores exposed to me and the ixgbe driver exposes 24 tx
>and 24 rx interrupts per NIC. I then pin the interrupts to cores for
>each NIC (each interrupt gets its own core, standard stuff).
>
>Anyway.... I'm only seeing RX interrupts on 16 of the 24 cores (random
>src/dest pairs across a /16 each, so I should be getting good flow
>hashing). Did I miss some magic somewhere?
>
>I'm running 2.6.32.4, perhaps this has been fixed upstream. If not,
>any thoughts on how to make this work?
>
>-A
>--
>To unsubscribe from this list: send the line "unsubscribe netdev" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] drivers/net: Call netif_carrier_off at the end of the probe
From: David Miller @ 2011-02-17 22:10 UTC (permalink / raw)
To: ivecera; +Cc: netdev, romieu, aabdulla
In-Reply-To: <1297771719-14202-1-git-send-email-ivecera@redhat.com>
From: Ivan Vecera <ivecera@redhat.com>
Date: Tue, 15 Feb 2011 13:08:39 +0100
> Without calling of netif_carrier_off at the end of the probe the operstate
> is unknown when the device is initially opened. By default the carrier is
> on so when the device is opened and netif_carrier_on is called the link
> watch event is not fired and operstate remains zero (unknown).
>
> This patch fixes this behavior in forcedeth and r8169.
>
> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Applied, thanks Ivan.
^ permalink raw reply
* Re: [PATCH net-2.6/stable] tg3: Restrict phy ioctl access
From: David Miller @ 2011-02-17 22:11 UTC (permalink / raw)
To: mcarlson; +Cc: netdev, stable
In-Reply-To: <1297810270-4690-1-git-send-email-mcarlson@broadcom.com>
From: "Matt Carlson" <mcarlson@broadcom.com>
Date: Tue, 15 Feb 2011 14:51:10 -0800
> If management firmware is present and the device is down, the firmware
> will assume control of the phy. If a phy access were allowed from the
> host, it will collide with firmware phy accesses, resulting in
> unpredictable behavior. This patch fixes the problem by disallowing phy
> accesses during the problematic condition.
>
> Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
> Reviewed-by: Michael Chan <mchan@broadcom.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 3/3] enic: Always use single transmit and single receive hardware queues per device
From: David Miller @ 2011-02-17 22:12 UTC (permalink / raw)
To: vkolluri; +Cc: netdev
In-Reply-To: <20110217185322.2476.10728.stgit@savbu-pc100.cisco.com>
From: Vasanthy Kolluri <vkolluri@cisco.com>
Date: Thu, 17 Feb 2011 10:53:22 -0800
> From: Vasanthy Kolluri <vkolluri@cisco.com>
>
>
>
> Signed-off-by: Christian Benvenuti <benve@cisco.com>
> Signed-off-by: Danny Guo <dannguo@cisco.com>
> Signed-off-by: Vasanthy Kolluri <vkolluri@cisco.com>
> Signed-off-by: Roopa Prabhu <roprabhu@cisco.com>
> Signed-off-by: David Wang <dwang2@cisco.com>
You can't make a very serious change like this with such a terse commit
message, you have to explain exactly why this change is being made.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 1/3] enic: Bug fix: Reset driver count of registered unicast addresses to zero during device reset
From: David Miller @ 2011-02-17 22:14 UTC (permalink / raw)
To: vkolluri; +Cc: netdev
In-Reply-To: <20110217185311.2476.27883.stgit@savbu-pc100.cisco.com>
From: Vasanthy Kolluri <vkolluri@cisco.com>
Date: Thu, 17 Feb 2011 10:53:12 -0800
> From: Vasanthy Kolluri <vkolluri@cisco.com>
>
> During a device reset, clear the counter for the no. of unicast addresses registered.
> Also, rename the routines that update unicast and multicast address lists.
>
> Signed-off-by: Christian Benvenuti <benve@cisco.com>
> Signed-off-by: Danny Guo <dannguo@cisco.com>
> Signed-off-by: Vasanthy Kolluri <vkolluri@cisco.com>
> Signed-off-by: Roopa Prabhu <roprabhu@cisco.com>
> Signed-off-by: David Wang <dwang2@cisco.com>
Applied.
^ 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