* Re: [PATCH net-next v5 02/14] bridge: Add vlan filtering infrastructure
From: Vlad Yasevich @ 2013-01-11 15:33 UTC (permalink / raw)
To: Shmulik Ladkani; +Cc: Stephen Hemminger, netdev, davem, bridge, mst
In-Reply-To: <20130111155354.4ff8aeac.shmulik.ladkani@gmail.com>
On 01/11/2013 08:53 AM, Shmulik Ladkani wrote:
> Hi,
>
> On Thu, 10 Jan 2013 20:14:01 -0500 Vlad Yasevich <vyasevic@redhat.com> wrote:
>> On 01/10/2013 05:10 PM, Stephen Hemminger wrote:
>>> Also the concept of different filters for egress vs ingress is feature
>>> madness. It doesn't make sense to have half-duplex connectivity.
>>
>> I am of the same opinion, but it actually simplified the code quite a
>> bit, but at the cost of additional memory footprint. If you find this
>> very objectionable, I can easily remove it.
>
> Haven't looked on the V5 series yet, but just to clarify:
>
> There's *no* different membership _filter_ for egress vs ingress.
> The vlan's membership map is consulted on both ingress and egress.
Right.
>
> However, upon egress, a vlan egress _policy_ should be applied, which
> determines whether the frame should egress tagged/untagged on the egress
> port.
Right. This is how it is implemented in this series and this is what
Stephen finds "mad". You can configure the policy that on egress the
packet is untagged, but on ingress it has to be tagged. This kind of
half-duplex configuration is very prone to errors.
-vlad
>
> The expected logic in detailed in [1] (please read "steps 1..5").
> and the data structures needed are:
> - per port: PVID
> - per VLAN: port membership map
> - per VLAN: port egress policy map
>
> Altough on 1st look it might look mad ;-)
> But, this is genuinely simple, highly configurable and allows great
> flexibility (IMO with no additional code complexity; Vlad can probably
> comment).
>
> The motivation is to be aligned with behavior and configurability of
> vlan switches.
>
> Regards,
> Shmulik
>
> [1]
> http://marc.info/?l=linux-netdev&m=135603447030826&w=2
>
^ permalink raw reply
* R: Re: R: Re: mtu issue with ipsec tunnel and netfilter snat
From: pupilla @ 2013-01-11 15:34 UTC (permalink / raw)
To: jengelh; +Cc: netdev
jengelh@inai.de wrote
>On Thursday 2013-01-10 17:46, pupilla@libero.it wrote:
>
>>jengelh@inai.de wrote:
>>>>
>>>>But why linux_gw_snat is not sending icmp need to frag packets to
>>>>10.148.12.23?
>>>
>>>Perhaps because ICMP was blocked erroneously?
>>
>>well, I don't see the icmp packets because tcpdump 'see' only the
>>incoming ipsec clear packets. Is there a way to see the outgoing clear
>>ipsec packets with tcpdump?
>
>Not with AF_PACKET sockets (tcpdump uses such), but you could with
>iptables -j LOG, NFLOG and TRACE they can be made visible. If you need
>the full packet, you can either patch up LOG to call the kernel hexdump
>functions, or use NFLOG - I think - to deliver it to any userspace
>program to do further processing. If all else fails, there is also
>NFQUEUE with which the packet can also be copied to userspace.
>
Thanks for the reply.
I have saved the esp packets with tcpdump and then
decrypted with wireshark. Indeed, the icmp need to
frag packets are being sent by the linux ipsec
gateway.
Thanks for support.
^ permalink raw reply
* Re: [PATCH] cpsw: Add support to read cpu MAC address
From: Russell King - ARM Linux @ 2013-01-11 15:47 UTC (permalink / raw)
To: Michal Bachraty
Cc: grant.likely, rob.herring, rob, devicetree-discuss, linux-doc,
linux-kernel, linux-arm-kernel, netdev
In-Reply-To: <1357917302-32550-1-git-send-email-michal.bachraty@streamunlimited.com>
On Fri, Jan 11, 2013 at 04:15:02PM +0100, Michal Bachraty wrote:
> + if (!request_mem_region(priv->conf_res->start,
> + resource_size(priv->conf_res), ndev->name)) {
> + dev_err(priv->dev, "failed request i/o region\n");
> + ret = -ENXIO;
> + goto clean_clk_ret;
> + }
> +
> + regs = ioremap(priv->conf_res->start,
> + resource_size(priv->conf_res));
> + if (!regs) {
> + dev_err(priv->dev, "unable to map i/o region\n");
> + goto clean_configuration_iores_ret;
> + }
In this day and age where error paths don't get any testing, and are
frequently buggy, where we have alternative APIs which make those paths
more reliable, I think we should do everything to make use of that.
And, to prove the point, your error paths are buggy. Yes, you release
the mem region correctly (well done for picking the right interface for
that!) but the ioremap() is never cleaned up.
So, any chance of converting the above to devm_request_and_ioremap() ?
Thanks.
^ permalink raw reply
* per route MTU settings
From: pupilla @ 2013-01-11 16:29 UTC (permalink / raw)
To: netdev
Hello everybody.
I have done some tests with per route
mtu settings.
Here is the results on the 10.81.104.254
linux box running 3.6.9 on Slackware 14
32bit:
ip route add 10.81.105.109/32 via 10.81.104.1 mtu lock 1450
ip route flush cache
ping -M do 10.81.105.109 -c 5 -s 1450
PING 10.81.105.109 (10.81.105.109) 1450(1478) bytes of data.
>From 10.81.104.254 icmp_seq=1 Frag needed and DF set (mtu = 1450)
>From 10.81.104.254 icmp_seq=1 Frag needed and DF set (mtu = 1450)
>From 10.81.104.254 icmp_seq=1 Frag needed and DF set (mtu = 1450)
>From 10.81.104.254 icmp_seq=1 Frag needed and DF set (mtu = 1450)
>From 10.81.104.254 icmp_seq=1 Frag needed and DF set (mtu = 1450)
Here is the results on my linux box with
ip address 10.81.104.126 (the default
gateway is 10.81.104.254) running linux
3.7.0 on Slackware 14 64bit
ping -M do 10.81.105.109 -c 5 -s 560
PING 10.81.105.109 (10.81.105.109) 560(588) bytes of data.
>From 10.81.104.254 icmp_seq=1 Frag needed and DF set (mtu = 576)
>From 10.81.104.126 icmp_seq=2 Frag needed and DF set (mtu = 576)
>From 10.81.104.126 icmp_seq=2 Frag needed and DF set (mtu = 576)
>From 10.81.104.126 icmp_seq=2 Frag needed and DF set (mtu = 576)
>From 10.81.104.126 icmp_seq=2 Frag needed and DF set (mtu = 576)
When packets are generated locally (on
the 10.81.104.254 box), linux icmp message
'need to frag' report the correct mtu of
next hop. Instead on the forwarded packets
(those that aren't originated on the 10.81.104.254
box), I always get the 576 value on the mtu
of nexthop.
Is this the expected behaviour?
Any response are welcome
TIA
^ permalink raw reply
* Re: Problem with IPv6 Route Cache
From: Roman Mamedov @ 2013-01-11 16:37 UTC (permalink / raw)
To: netdev
In-Reply-To: <20130111185126.56cababe@natsu>
[-- Attachment #1: Type: text/plain, Size: 1006 bytes --]
Hello,
I have discovered that when the problem is occuring, I have:
root@neru:~# ip -6 neigh
fd39:20::39 dev tun-rm FAILED
fe80::20b:45ff:fe80:c000 dev eth0 lladdr 00:0b:45:80:c0:00 router REACHABLE
2a02:e00:ffff:56::1 dev eth0 lladdr 00:0b:45:80:c0:00 router REACHABLE
Launching "ping6 fd39:20::39" turns fd39:20::39 from FAILED to REACHABLE.
After that, "ip -6 route flush cache" actually succeeds in removing the route
via default gateway, and I then get the proper route entry:
root@neru:~# ip -6 route get fd39::100
fd39::100 from :: via fd39:20::39 dev tun-rm src fd39:20::3 metric 0
cache
So I conclude that my issue is very similar to [1] mentioned in a Bugzilla
entry [2] linked here just today.
[1] https://lkml.org/lkml/2012/5/25/96
[2] https://bugzilla.kernel.org/show_bug.cgi?id=42991
--
With respect,
Roman
~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Stallman had a printer,
with code he could not see.
So he began to tinker,
and set the software free."
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH 1/2] [iproute2] add man7 to subdirs list
From: Mike Frysinger @ 2013-01-11 16:56 UTC (permalink / raw)
To: stephen.hemminger, netdev
The man dir misses the man7 as a subdir which means none of the pages
get installed.
URL: https://bugs.gentoo.org/451166
Reported-by: Marcin Mirosław <bug@mejor.pl>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
man/Makefile | 2 +-
man/man7/Makefile | 13 +++++++++++++
2 files changed, 14 insertions(+), 1 deletion(-)
create mode 100644 man/man7/Makefile
diff --git a/man/Makefile b/man/Makefile
index 67fea05..9a60fa7 100644
--- a/man/Makefile
+++ b/man/Makefile
@@ -2,7 +2,7 @@ INSTALL=install
INSTALLDIR=install -m 0755 -d
INSTALLMAN=install -m 0644
-SUBDIRS = man3 man8
+SUBDIRS = man3 man7 man8
all:
@for subdir in $(SUBDIRS); do $(MAKE) -C $$subdir; done
diff --git a/man/man7/Makefile b/man/man7/Makefile
new file mode 100644
index 0000000..ccfd839
--- /dev/null
+++ b/man/man7/Makefile
@@ -0,0 +1,13 @@
+MAN7PAGES = tc-hfsc.7
+
+all:
+
+distclean: clean
+
+clean:
+
+install:
+ $(INSTALLDIR) $(DESTDIR)$(MANDIR)/man7
+ $(INSTALLMAN) $(MAN7PAGES) $(DESTDIR)$(MANDIR)/man7
+
+.PHONY: install clean distclean
--
1.8.0.2
^ permalink raw reply related
* [PATCH 2/2] [iproute2] do not ignore errors in man subdirs
From: Mike Frysinger @ 2013-01-11 16:56 UTC (permalink / raw)
To: stephen.hemminger, netdev
In-Reply-To: <1357923389-20114-1-git-send-email-vapier@gentoo.org>
If an error occurs in a man subdir, make sure we propagate it back up.
While we're here, merge the duplicate rules into one.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
man/Makefile | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/man/Makefile b/man/Makefile
index 9a60fa7..749faa1 100644
--- a/man/Makefile
+++ b/man/Makefile
@@ -4,17 +4,11 @@ INSTALLMAN=install -m 0644
SUBDIRS = man3 man7 man8
-all:
- @for subdir in $(SUBDIRS); do $(MAKE) -C $$subdir; done
+all clean install:
+ @for subdir in $(SUBDIRS); do $(MAKE) -C $$subdir $@ || exit $$?; done
distclean: clean
-clean:
- @for subdir in $(SUBDIRS); do $(MAKE) -C $$subdir clean; done
-
-install:
- @for subdir in $(SUBDIRS); do $(MAKE) -C $$subdir install; done
-
.PHONY: install clean distclean
.EXPORT_ALL_VARIABLES:
--
1.8.0.2
^ permalink raw reply related
* Re: [net-next 09/15] e1000e: resolve checkpatch PREFER_PR_LEVEL warning
From: Joe Perches @ 2013-01-11 17:03 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: davem, Bruce Allan, netdev, gospo, sassmann
In-Reply-To: <1357899831-4168-10-git-send-email-jeffrey.t.kirsher@intel.com>
On Fri, 2013-01-11 at 02:23 -0800, Jeff Kirsher wrote:
> WARNING: Prefer netdev_info(netdev, ... then dev_info(dev, ...
> then pr_info(... to printk(KERN_INFO ...
[]
> diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
[]
> @@ -4300,9 +4300,8 @@ static void e1000_print_link_info(struct e1000_adapter *adapter)
> u32 ctrl = er32(CTRL);
>
> /* Link status message must follow this format for user tools */
> - printk(KERN_INFO "e1000e: %s NIC Link is Up %d Mbps %s Duplex, Flow Control: %s\n",
> - adapter->netdev->name,
> - adapter->link_speed,
> + pr_info("e1000e: %s NIC Link is Up %d Mbps %s Duplex, Flow Control: %s\n",
> + adapter->netdev->name, adapter->link_speed,
Don't these changes break a user-space tool?
If not, please remove the comment above the pr_info()s
and remove the unnecessary e1000e: prefixes.
> @@ -4521,8 +4520,8 @@ static void e1000_watchdog_task(struct work_struct *work)
[]
> /* Link status message must follow this format */
> - printk(KERN_INFO "e1000e: %s NIC Link is Down\n",
> - adapter->netdev->name);
> + pr_info("e1000e: %s NIC Link is Down\n",
> + adapter->netdev->name);
^ permalink raw reply
* Re: [PATCH net-next v5 01/14] vlan: wrap hw-acceleration calls in separate functions.
From: Stephen Hemminger @ 2013-01-11 17:20 UTC (permalink / raw)
To: vyasevic; +Cc: mst, netdev, stephen, bridge, shmulik.ladkani, davem
In-Reply-To: <50EF660B.2090500@redhat.com>
What I think is the least intrusive and allows for maximum flexibility
is having the VLAN bridge filtering depend on VLAN support (CONFIG_VLAN_8021Q).
There already is drivers that depend on that value to enable filtering.
And make the support of VLAN filtering in the bridge conditional like
IGMP snooping is optional
--- a/net/bridge/Kconfig
+++ b/net/bridge/Kconfig
@@ -46,3 +46,17 @@ config BRIDGE_IGMP_SNOOPING
Say N to exclude this support and reduce the binary size.
If unsure, say Y.
+
+config BRIDGE_VLAN_FILTERING
+ bool "VLAN filtering"
+ depends on BRIDGE
+ depends on VLAN_8021Q
+ default n
+ ---help---
+ If you say Y here, then the Ethernet bridge will be able to
+ selectively filter traffic based on VLAN tag.
+
+ Say N to exclude this support and reduce the binary size.
+
+ If unsure, say Y.
^ permalink raw reply
* Re: [PATCH net-next v5 01/14] vlan: wrap hw-acceleration calls in separate functions.
From: Vlad Yasevich @ 2013-01-11 17:41 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, davem, stephen, bridge, shmulik.ladkani, mst
In-Reply-To: <20130111092004.2d55ae65@nehalam.linuxnetplumber.net>
On 01/11/2013 12:20 PM, Stephen Hemminger wrote:
> What I think is the least intrusive and allows for maximum flexibility
> is having the VLAN bridge filtering depend on VLAN support (CONFIG_VLAN_8021Q).
> There already is drivers that depend on that value to enable filtering.
>
The only thing that I see depending on CONFIG_VLAN_8021Q is
CONFIG_VLAN_8021Q_GVRP which is part of the 8021Q support.
There are currently no other drivers depending on 8021Q functionality
and vlan filtering in drivers doesn't depend on 8021Q support in
the kernel.
I admit that I've thought of having a dependency on 8021Q as it would
have allowed me to re-use a bit more code, but decided that bridge
should be able to stand on its own in this regard. 8021Q is not
necessary to turn on VLAN accelerated filtering on the nics as anyone
can do it through the ndo_vlan_rx_add_vid() call.
The reason for this patch was to make the nic vlan filter code reusable
and address Jiri Pirko's comment in the V2 series.
(http://marc.info/?l=linux-netdev&m=135590565719164&w=2). This way,
bridge wouldn't need to make direct ndo_ calls and all call sights will
be consistent.
> And make the support of VLAN filtering in the bridge conditional like
> IGMP snooping is optional
I could certainly make the VLAN filtering conditional, but I am not sure
what it would buy us other then a lot of ifdefs.
Thanks
-vlad
>
> --- a/net/bridge/Kconfig
> +++ b/net/bridge/Kconfig
> @@ -46,3 +46,17 @@ config BRIDGE_IGMP_SNOOPING
> Say N to exclude this support and reduce the binary size.
>
> If unsure, say Y.
> +
> +config BRIDGE_VLAN_FILTERING
> + bool "VLAN filtering"
> + depends on BRIDGE
> + depends on VLAN_8021Q
> + default n
> + ---help---
> + If you say Y here, then the Ethernet bridge will be able to
> + selectively filter traffic based on VLAN tag.
> +
> + Say N to exclude this support and reduce the binary size.
> +
> + If unsure, say Y.
>
^ permalink raw reply
* RE: [net-next 09/15] e1000e: resolve checkpatch PREFER_PR_LEVEL warning
From: Allan, Bruce W @ 2013-01-11 18:05 UTC (permalink / raw)
To: Joe Perches, Kirsher, Jeffrey T
Cc: davem@davemloft.net, netdev@vger.kernel.org, gospo@redhat.com,
sassmann@redhat.com
In-Reply-To: <1357923819.2327.5.camel@joe-AO722>
> -----Original Message-----
> From: Joe Perches [mailto:joe@perches.com]
> Sent: Friday, January 11, 2013 9:04 AM
> To: Kirsher, Jeffrey T
> Cc: davem@davemloft.net; Allan, Bruce W; netdev@vger.kernel.org;
> gospo@redhat.com; sassmann@redhat.com
> Subject: Re: [net-next 09/15] e1000e: resolve checkpatch PREFER_PR_LEVEL
> warning
>
> On Fri, 2013-01-11 at 02:23 -0800, Jeff Kirsher wrote:
> > WARNING: Prefer netdev_info(netdev, ... then dev_info(dev, ...
> > then pr_info(... to printk(KERN_INFO ...
> []
> > diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
> b/drivers/net/ethernet/intel/e1000e/netdev.c
> []
> > @@ -4300,9 +4300,8 @@ static void e1000_print_link_info(struct
> e1000_adapter *adapter)
> > u32 ctrl = er32(CTRL);
> >
> > /* Link status message must follow this format for user tools */
> > - printk(KERN_INFO "e1000e: %s NIC Link is Up %d Mbps %s Duplex,
> Flow Control: %s\n",
> > - adapter->netdev->name,
> > - adapter->link_speed,
> > + pr_info("e1000e: %s NIC Link is Up %d Mbps %s Duplex, Flow
> Control: %s\n",
> > + adapter->netdev->name, adapter->link_speed,
>
> Don't these changes break a user-space tool?
>
> If not, please remove the comment above the pr_info()s
> and remove the unnecessary e1000e: prefixes.
>
> > @@ -4521,8 +4520,8 @@ static void e1000_watchdog_task(struct
> work_struct *work)
> []
> > /* Link status message must follow this format */
> > - printk(KERN_INFO "e1000e: %s NIC Link is Down\n",
> > - adapter->netdev->name);
> > + pr_info("e1000e: %s NIC Link is Down\n",
> > + adapter->netdev->name);
>
Hmm, I'm not sure how that got past our testing even after I asked to check for
redundant instances of "e1000e". This patch can be dropped and I will submit an
updated one but it will still have the "must follow this format for user tools" comment
since the user tools key off of "e1000e: <iface> NIC Link is ..." text.
Thanks,
Bruce.
^ permalink raw reply
* Re: [PATCH net-next v5 01/14] vlan: wrap hw-acceleration calls in separate functions.
From: Stephen Hemminger @ 2013-01-11 18:23 UTC (permalink / raw)
To: vyasevic; +Cc: netdev, davem, stephen, bridge, shmulik.ladkani, mst
In-Reply-To: <50F04EDC.9040309@redhat.com>
On Fri, 11 Jan 2013 12:41:48 -0500
Vlad Yasevich <vyasevic@redhat.com> wrote:
> On 01/11/2013 12:20 PM, Stephen Hemminger wrote:
> > What I think is the least intrusive and allows for maximum flexibility
> > is having the VLAN bridge filtering depend on VLAN support (CONFIG_VLAN_8021Q).
> > There already is drivers that depend on that value to enable filtering.
> >
>
> The only thing that I see depending on CONFIG_VLAN_8021Q is
> CONFIG_VLAN_8021Q_GVRP which is part of the 8021Q support.
> There are currently no other drivers depending on 8021Q functionality
> and vlan filtering in drivers doesn't depend on 8021Q support in
> the kernel.
>
> I admit that I've thought of having a dependency on 8021Q as it would
> have allowed me to re-use a bit more code, but decided that bridge
> should be able to stand on its own in this regard. 8021Q is not
> necessary to turn on VLAN accelerated filtering on the nics as anyone
> can do it through the ndo_vlan_rx_add_vid() call.
>
> The reason for this patch was to make the nic vlan filter code reusable
> and address Jiri Pirko's comment in the V2 series.
> (http://marc.info/?l=linux-netdev&m=135590565719164&w=2). This way,
> bridge wouldn't need to make direct ndo_ calls and all call sights will
> be consistent.
>
> > And make the support of VLAN filtering in the bridge conditional like
> > IGMP snooping is optional
>
> I could certainly make the VLAN filtering conditional, but I am not sure
> what it would buy us other then a lot of ifdefs.
>
> Thanks
> -vlad
>
> >
> > --- a/net/bridge/Kconfig
> > +++ b/net/bridge/Kconfig
> > @@ -46,3 +46,17 @@ config BRIDGE_IGMP_SNOOPING
> > Say N to exclude this support and reduce the binary size.
> >
> > If unsure, say Y.
> > +
> > +config BRIDGE_VLAN_FILTERING
> > + bool "VLAN filtering"
> > + depends on BRIDGE
> > + depends on VLAN_8021Q
> > + default n
> > + ---help---
> > + If you say Y here, then the Ethernet bridge will be able to
> > + selectively filter traffic based on VLAN tag.
> > +
> > + Say N to exclude this support and reduce the binary size.
> > +
> > + If unsure, say Y.
> >
>
Doing the following shows several drivers that still depend on VLAN_8021Q being
enabled to do VLAN tagging.
$ git grep -l CONFIG_VLAN_8021Q
ethernet/3com/3c59x.c
ethernet/adaptec/starfire.c
ethernet/amd/amd8111e.c
ethernet/broadcom/cnic.c
ethernet/broadcom/tg3.c
ethernet/dlink/sundance.c
ethernet/natsemi/ns83820.c
ethernet/sis/sis900.c
ethernet/sis/sis900.h
ethernet/stmicro/stmmac/common.h
^ permalink raw reply
* Re: [PATCH 0/3] ixgbe: request_firmware for configuration parameters
From: Greg KH @ 2013-01-11 18:25 UTC (permalink / raw)
To: Shannon Nelson; +Cc: netdev, davem, dwmw2, jeffrey.t.kirsher, linux-kernel
In-Reply-To: <20130111020046.15463.72333.stgit@starfish.jf.intel.com>
On Thu, Jan 10, 2013 at 06:02:20PM -0800, Shannon Nelson wrote:
> Most networking dials and knobs can be set using ethtool, ifconfig, ip link
> commands, or sysfs entries, all of which can be driven by startup scripts
> and other configuration tools. However, they all depend on having a netdev
> already set up, and we have some low-level device functionality that needs
> to be sorted out before we start setting up MSI-x and memory allocations.
>
> In order to do early device configuration, most kernel drivers use module
> parameters whose settings can be persisted in modprobe.d config files.
> However, these can be clumsy to use and manage, difficult to specify port
> specific values in a multiport device, and are actively discouraged in
> some circles.
>
> In this patchset, the driver uses the existing request_firmware() and
> match_token() facilities to grab an ASCII config file from userspace to
> find special startup-time configuration information that needs persistence
> across reboots. The configuration strings are formed similar to the
> mount options that get passed from /etc/fstab into filesystem modules.
Ick, please don't abuse request_firmware() for this type of thing.
What's wrong with configfs? It sounds like it will fit your need, and
that is what is created for.
greg k-h
^ permalink raw reply
* RE: per route MTU settings
From: Lukas Tribus @ 2013-01-11 18:35 UTC (permalink / raw)
To: pupilla, netdev
In-Reply-To: <22271727.642511357921768466.JavaMail.defaultUser@defaultHost>
Hi,
10.81.104.254 will never transmit anything with
> ping -M do 10.81.105.109 -c 5 -s 1450
because the host already knows a 1478 Byte packet won't fit the
1450 Byte route you made towards 10.81.104.1.
You do realize that 1450 is your ICMP payload, plus ICMP header (8B)
and IP header (20B) and you are at 1478B, which exceeds your route's
MTU.
I guess 10.81.104.1 has a 576B MTU route/interface towards
10.81.105.109, and you did the first test on 10.81.104.254,
and only afterwards you tried "-s 560" from .126, so only
then the .254 host realized the transport to 10.81.104.1
is actually a 576B MTU path.
You cannot do pings with 2 different packet sizes on 2 different hosts,
and expect them to behave exactly the same.
Running from both hosts pings with:
-s 548
-s 549
-s 1422
-s 1423
and then analyzing the results will probably give us a better
idea of what actually happens.
Regards,
Lukas
----------------------------------------
> Date: Fri, 11 Jan 2013 17:29:28 +0100
> From: pupilla@libero.it
> To: netdev@vger.kernel.org
> Subject: per route MTU settings
>
> Hello everybody.
>
> I have done some tests with per route
> mtu settings.
>
> Here is the results on the 10.81.104.254
> linux box running 3.6.9 on Slackware 14
> 32bit:
>
> ip route add 10.81.105.109/32 via 10.81.104.1 mtu lock 1450
> ip route flush cache
>
> ping -M do 10.81.105.109 -c 5 -s 1450
> PING 10.81.105.109 (10.81.105.109) 1450(1478) bytes of data.
> From 10.81.104.254 icmp_seq=1 Frag needed and DF set (mtu = 1450)
> From 10.81.104.254 icmp_seq=1 Frag needed and DF set (mtu = 1450)
> From 10.81.104.254 icmp_seq=1 Frag needed and DF set (mtu = 1450)
> From 10.81.104.254 icmp_seq=1 Frag needed and DF set (mtu = 1450)
> From 10.81.104.254 icmp_seq=1 Frag needed and DF set (mtu = 1450)
>
> Here is the results on my linux box with
> ip address 10.81.104.126 (the default
> gateway is 10.81.104.254) running linux
> 3.7.0 on Slackware 14 64bit
>
> ping -M do 10.81.105.109 -c 5 -s 560
> PING 10.81.105.109 (10.81.105.109) 560(588) bytes of data.
> From 10.81.104.254 icmp_seq=1 Frag needed and DF set (mtu = 576)
> From 10.81.104.126 icmp_seq=2 Frag needed and DF set (mtu = 576)
> From 10.81.104.126 icmp_seq=2 Frag needed and DF set (mtu = 576)
> From 10.81.104.126 icmp_seq=2 Frag needed and DF set (mtu = 576)
> From 10.81.104.126 icmp_seq=2 Frag needed and DF set (mtu = 576)
>
> When packets are generated locally (on
> the 10.81.104.254 box), linux icmp message
> 'need to frag' report the correct mtu of
> next hop. Instead on the forwarded packets
> (those that aren't originated on the 10.81.104.254
> box), I always get the 576 value on the mtu
> of nexthop.
> Is this the expected behaviour?
>
> Any response are welcome
>
> TIA
> --
> 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
* [PATCH] net: Export __netdev_pick_tx so that it can be used in modules
From: Alexander Duyck @ 2013-01-11 18:38 UTC (permalink / raw)
To: netdev; +Cc: davem
When testing with FCoE enabled we discovered that I had not exported
__netdev_pick_tx. As a result ixgbe doesn't build with the RFC patches
applied because ixgbe_select_queue was calling the function. This change
corrects that build issue by correctly exporting __netdev_pick_tx so it
can be used by modules.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
---
net/core/dev.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 95de4c0..d1e8116 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2746,6 +2746,7 @@ u16 __netdev_pick_tx(struct net_device *dev, struct sk_buff *skb)
return queue_index;
}
+EXPORT_SYMBOL(__netdev_pick_tx);
struct netdev_queue *netdev_pick_tx(struct net_device *dev,
struct sk_buff *skb)
^ permalink raw reply related
* Re: [PATCH net-next v5 01/14] vlan: wrap hw-acceleration calls in separate functions.
From: Vlad Yasevich @ 2013-01-11 18:53 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, davem, stephen, bridge, shmulik.ladkani, mst
In-Reply-To: <20130111102318.579abe94@nehalam.linuxnetplumber.net>
On 01/11/2013 01:23 PM, Stephen Hemminger wrote:
> On Fri, 11 Jan 2013 12:41:48 -0500
> Vlad Yasevich <vyasevic@redhat.com> wrote:
>
>> On 01/11/2013 12:20 PM, Stephen Hemminger wrote:
>>> What I think is the least intrusive and allows for maximum flexibility
>>> is having the VLAN bridge filtering depend on VLAN support (CONFIG_VLAN_8021Q).
>>> There already is drivers that depend on that value to enable filtering.
>>>
>>
>> The only thing that I see depending on CONFIG_VLAN_8021Q is
>> CONFIG_VLAN_8021Q_GVRP which is part of the 8021Q support.
>> There are currently no other drivers depending on 8021Q functionality
>> and vlan filtering in drivers doesn't depend on 8021Q support in
>> the kernel.
>>
>> I admit that I've thought of having a dependency on 8021Q as it would
>> have allowed me to re-use a bit more code, but decided that bridge
>> should be able to stand on its own in this regard. 8021Q is not
>> necessary to turn on VLAN accelerated filtering on the nics as anyone
>> can do it through the ndo_vlan_rx_add_vid() call.
>>
>> The reason for this patch was to make the nic vlan filter code reusable
>> and address Jiri Pirko's comment in the V2 series.
>> (http://marc.info/?l=linux-netdev&m=135590565719164&w=2). This way,
>> bridge wouldn't need to make direct ndo_ calls and all call sights will
>> be consistent.
>>
>>> And make the support of VLAN filtering in the bridge conditional like
>>> IGMP snooping is optional
>>
>> I could certainly make the VLAN filtering conditional, but I am not sure
>> what it would buy us other then a lot of ifdefs.
>>
>> Thanks
>> -vlad
>>
>>>
>>> --- a/net/bridge/Kconfig
>>> +++ b/net/bridge/Kconfig
>>> @@ -46,3 +46,17 @@ config BRIDGE_IGMP_SNOOPING
>>> Say N to exclude this support and reduce the binary size.
>>>
>>> If unsure, say Y.
>>> +
>>> +config BRIDGE_VLAN_FILTERING
>>> + bool "VLAN filtering"
>>> + depends on BRIDGE
>>> + depends on VLAN_8021Q
>>> + default n
>>> + ---help---
>>> + If you say Y here, then the Ethernet bridge will be able to
>>> + selectively filter traffic based on VLAN tag.
>>> +
>>> + Say N to exclude this support and reduce the binary size.
>>> +
>>> + If unsure, say Y.
>>>
>>
>
> Doing the following shows several drivers that still depend on VLAN_8021Q being
> enabled to do VLAN tagging.
> $ git grep -l CONFIG_VLAN_8021Q
> ethernet/3com/3c59x.c
> ethernet/adaptec/starfire.c
> ethernet/amd/amd8111e.c
> ethernet/broadcom/cnic.c
> ethernet/broadcom/tg3.c
> ethernet/dlink/sundance.c
> ethernet/natsemi/ns83820.c
> ethernet/sis/sis900.c
> ethernet/sis/sis900.h
> ethernet/stmicro/stmmac/common.h
OK. You've convinced me. I can make my code depend on 8021Q and move
these functions into vlan module.
I'll update the series with these changes.
-vlad
^ permalink raw reply
* Re: [PATCH] net: Export __netdev_pick_tx so that it can be used in modules
From: John Fastabend @ 2013-01-11 19:02 UTC (permalink / raw)
To: Alexander Duyck; +Cc: netdev, davem
In-Reply-To: <20130111183842.6152.34578.stgit@ahduyck-cp1.jf.intel.com>
On 1/11/2013 10:38 AM, Alexander Duyck wrote:
> When testing with FCoE enabled we discovered that I had not exported
> __netdev_pick_tx. As a result ixgbe doesn't build with the RFC patches
> applied because ixgbe_select_queue was calling the function. This change
> corrects that build issue by correctly exporting __netdev_pick_tx so it
> can be used by modules.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> ---
Hi Alex,
If we get XPS to play nicely with the traffic class schemes we
can just remove select_queue completely.
I'll take a look tomorrow.
Thanks,
John
^ permalink raw reply
* Re: qmi_wwan on Huawei E398
From: Bjørn Mork @ 2013-01-11 19:27 UTC (permalink / raw)
To: Cedric Jehasse, netdev
In-Reply-To: <CABvLYuAX=r_Y0AdDtNp5g0kRYeP6suhLe_b68a7sQYJ-i7wrvg@mail.gmail.com>
Cedric Jehasse <cedric.jehasse@gmail.com> wrote:
>Hi,
>
>I'm trying to use qmi on an Huawei E398 dongle with ofono on a 3.7.1
>kernel. (this works with a 3.5.0 kernel)
>ofono looks for the class/subclass/protocol of the parent
>usb_interface device for the qmi_wwan and cdc_wdm devices. This must
>match with ff/01/08 and ff/01/09 Cls/Sub/Prot.
>
>Below is a trace of the udev events and usb-device output for a 3.5.0
>and 3.7.1 kernel. The difference is in the parent devices for wwan0
>and cdc-wdm0.
>The parent device for wwan0 is on a 3.7.1 kernel is If3. Is this
>normal?
>
>* 3.5.0:
>KERNEL[201.262240] add
>/devices/pci0000:00/0000:00:1d.7/usb2/2-6/2-6:1.3/usb/cdc-wdm0 (usb)
>KERNEL[201.347292] add
>/devices/pci0000:00/0000:00:1d.7/usb2/2-6/2-6:1.4/net/wwan0 (net)
>
>T: Bus=02 Lev=01 Prnt=01 Port=05 Cnt=01 Dev#= 4 Spd=480 MxCh= 0
>D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
>P: Vendor=12d1 ProdID=150a Rev=00.00
>S: Manufacturer=Huawei Technologies
>S: Product=HUAWEI Mobile
>S: SerialNumber=1234567890ABCDEF
>C: #Ifs= 7 Cfg#= 1 Atr=c0 MxPwr=500mA
>I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=option
>I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=02 Driver=option
>I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=03 Driver=option
>I: If#= 3 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=01 Prot=09 Driver=cdc_wdm
>I: If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=08 Driver=qmi_wwan
>I: If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50
>Driver=usb-storage
>I: If#= 6 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50
>Driver=usb-storage
>
>* 3.7.1:
>KERNEL[61750.414019] add
>/devices/pci0000:00/0000:00:1d.7/usb2/2-6/2-6:1.3/usbmisc/cdc-wdm0
>(usbmisc)
>KERNEL[61750.414019] add
>/devices/pci0000:00/0000:00:1d.7/usb2/2-6/2-6:1.3/usbmisc/cdc-wdm0
>(usbmisc)
>
>T: Bus=02 Lev=01 Prnt=01 Port=05 Cnt=01 Dev#= 6 Spd=480 MxCh= 0
>D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
>P: Vendor=12d1 ProdID=150a Rev=00.00
>S: Manufacturer=Huawei Technologies
>S: Product=HUAWEI Mobile
>S: SerialNumber=1234567890ABCDEF
>C: #Ifs= 7 Cfg#= 1 Atr=c0 MxPwr=500mA
>I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=option
>I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=02 Driver=option
>I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=03 Driver=option
>I: If#= 3 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=01 Prot=09 Driver=qmi_wwan
>I: If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=08 Driver=qmi_wwan
>I: If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50
>Driver=usb-storage
>I: If#= 6 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50
>Driver=usb-storage
>
>Thanks,
>Cedric
This looks right to me. There is a single function using two USB interfaces. We started out letting the cdc-wdm driver handle the control interface and the qmi_wwan driver the data interface. This is what you see in 3.5. But splitting a function like this was very awkward and made devices like the E398 behave differently from most other QMI devices, which only use a single USB interface.
So we changed this to let the qmi_wwan driver handle both interfaces. This is what you see in 3.7. The control interface is now the parent of both the cdc_wdm character device and the wwan network device and the data interface is just a data interface.
I realize that this is balancing on the edge of acceptable userspace visible changes, but all this did was making devices like the E398 look similar to single interface devices. Which already had to be supported by the userspace applications.
Now I understand that ofono does a lot stricter matching than I have anticipated, looking at the vendor specific subclass and protocol fields of the wwan parent interface. I don't think we can fix that without updating ofono. Sorry. If it is going to do that then it needs to accept both ff/01/08 and ff/01/09.
Bjørn
^ permalink raw reply
* Re: [PATCH 0/3] ixgbe: request_firmware for configuration parameters
From: Shannon Nelson @ 2013-01-11 19:30 UTC (permalink / raw)
To: Greg KH; +Cc: netdev, davem, dwmw2, jeffrey.t.kirsher, linux-kernel
In-Reply-To: <20130111182547.GA22231@kroah.com>
On Fri, Jan 11, 2013 at 10:25 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Thu, Jan 10, 2013 at 06:02:20PM -0800, Shannon Nelson wrote:
>> Most networking dials and knobs can be set using ethtool, ifconfig, ip link
>> commands, or sysfs entries, all of which can be driven by startup scripts
>> and other configuration tools. However, they all depend on having a netdev
>> already set up, and we have some low-level device functionality that needs
>> to be sorted out before we start setting up MSI-x and memory allocations.
> Ick, please don't abuse request_firmware() for this type of thing.
Yeah, it seemed ugly to me at first as well, but it grew on me as I
realized that it does solve a problem in a rather elegant way. While
working this up I discussed this with Mr. Woodhouse thinking that as a
firmware tree maintainer he'd have a similar reaction, but he actually
wasn't opposed to it (David, please speak up if I'm misrepresenting
your comments).
> What's wrong with configfs? It sounds like it will fit your need, and
> that is what is created for.
configfs has similar problems as sysfs - the driver needs to create
the hooks before it has all the info it might need for some hooks,
there is no persistence across reboots, and I don't think it will help
for initrd images. Additionally, there would need to be some userland
mechanism to notice that the hooks were there and to feed it the
startup info. Using a file in the firmware path gives us persistence
and a way for the driver to get info before having to set up
filesystem hooks. It also gives us a way to get special config info
into the boot image. And the whole mechanism already exists,
including UDEV hooks that can do more fancy stuff if needed.
sln
--
==============================================
Mr. Shannon Nelson Parents can't afford to be squeamish.
^ permalink raw reply
* Re: [PATCH 0/3] ixgbe: request_firmware for configuration parameters
From: Greg KH @ 2013-01-11 19:41 UTC (permalink / raw)
To: Shannon Nelson; +Cc: netdev, davem, dwmw2, jeffrey.t.kirsher, linux-kernel
In-Reply-To: <CAP-MU4MzG_P9fz3_eix=zgzyjijZ5qo1mpKE=r_K7y3xcJqc5Q@mail.gmail.com>
On Fri, Jan 11, 2013 at 11:30:54AM -0800, Shannon Nelson wrote:
> On Fri, Jan 11, 2013 at 10:25 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Thu, Jan 10, 2013 at 06:02:20PM -0800, Shannon Nelson wrote:
> >> Most networking dials and knobs can be set using ethtool, ifconfig, ip link
> >> commands, or sysfs entries, all of which can be driven by startup scripts
> >> and other configuration tools. However, they all depend on having a netdev
> >> already set up, and we have some low-level device functionality that needs
> >> to be sorted out before we start setting up MSI-x and memory allocations.
>
> > Ick, please don't abuse request_firmware() for this type of thing.
>
> Yeah, it seemed ugly to me at first as well, but it grew on me as I
> realized that it does solve a problem in a rather elegant way. While
> working this up I discussed this with Mr. Woodhouse thinking that as a
> firmware tree maintainer he'd have a similar reaction, but he actually
> wasn't opposed to it (David, please speak up if I'm misrepresenting
> your comments).
David maintains the external firmware tree repo, not the in-kernel
firmware core code (which I used to maintain.)
> > What's wrong with configfs? It sounds like it will fit your need, and
> > that is what is created for.
>
> configfs has similar problems as sysfs - the driver needs to create
> the hooks before it has all the info it might need for some hooks,
> there is no persistence across reboots, and I don't think it will help
> for initrd images. Additionally, there would need to be some userland
> mechanism to notice that the hooks were there and to feed it the
> startup info. Using a file in the firmware path gives us persistence
> and a way for the driver to get info before having to set up
> filesystem hooks. It also gives us a way to get special config info
> into the boot image. And the whole mechanism already exists,
> including UDEV hooks that can do more fancy stuff if needed.
Yes, but you are now starting to use "configuration files" for kernel
drivers, which we have resisted for 20+ years for a variety of good
reasons. You can't just ignore all of the arguments to not do this all
of a sudden because you feel your driver is somehow "special" here.
All of the above issues you seem to have with sysfs and configfs can be
resolved with userspace code, and having your driver not do anything to
the hardware until it is told to by userspace.
The boot image problem is harder, but I would argue that your driver
better fall-back to some "known good" configuration for that type of
instance, as you will need to do that anyway if your "firmware" file
isn't present in the first place.
So please try configfs again, the idea of loading configuration files
from the filesystem, no matter what the mechanism, into your driver,
isn't ok to do, sorry.
greg k-h
^ permalink raw reply
* Re: [PATCH v3] net, wireless: overwrite default_ethtool_ops
From: Ben Hutchings @ 2013-01-11 20:00 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: netdev, David S. Miller, Eric Dumazet, Ben Greear,
Bjørn Mork, linux-wireless, Michał Mirosław,
Johannes Berg
In-Reply-To: <20130111091909.GA2347@redhat.com>
On Fri, 2013-01-11 at 10:19 +0100, Stanislaw Gruszka wrote:
> Since:
>
> commit 2c60db037034d27f8c636403355d52872da92f81
> Author: Eric Dumazet <edumazet@google.com>
> Date: Sun Sep 16 09:17:26 2012 +0000
>
> net: provide a default dev->ethtool_ops
>
> wireless core does not correctly assign ethtool_ops.
>
> After alloc_netdev*() call, some cfg80211 drivers provide they own
> ethtool_ops, but some do not. For them, wireless core provide generic
> cfg80211_ethtool_ops, which is assigned in NETDEV_REGISTER notify call:
>
> if (!dev->ethtool_ops)
> dev->ethtool_ops = &cfg80211_ethtool_ops;
>
> But after Eric's commit, dev->ethtool_ops is no longer NULL (on cfg80211
> drivers without custom ethtool_ops), but points to &default_ethtool_ops.
>
> In order to fix the problem, provide function which will overwrite
> default_ethtool_ops and use it by wireless core.
>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
[...]
Acked-by: Ben Hutchings <bhutchings@solarflare.com>
--
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 net-next] ipv4: fib: fix a comment.
From: Rami Rosen @ 2013-01-11 19:59 UTC (permalink / raw)
To: davem; +Cc: netdev, Rami Rosen
In fib_frontend.c, there is a confusing comment; NETLINK_CB(skb).portid does not
refer to a pid of sending process, but rather to a netlink portid.
Signed-off-by: Rami Rosen <ramirose@gmail.com>
---
net/ipv4/fib_frontend.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
index 5cd75e2..99f00d3 100644
--- a/net/ipv4/fib_frontend.c
+++ b/net/ipv4/fib_frontend.c
@@ -974,7 +974,7 @@ static void nl_fib_input(struct sk_buff *skb)
nl_fib_lookup(frn, tb);
- portid = NETLINK_CB(skb).portid; /* pid of sending process */
+ portid = NETLINK_CB(skb).portid; /* netlink portid */
NETLINK_CB(skb).portid = 0; /* from kernel */
NETLINK_CB(skb).dst_group = 0; /* unicast */
netlink_unicast(net->ipv4.fibnl, skb, portid, MSG_DONTWAIT);
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH/RFC] ipv6: fib: Drop cached routes with dead neighbours on fib GC
From: Roland Dreier @ 2013-01-11 21:10 UTC (permalink / raw)
To: David S. Miller, netdev@vger.kernel.org
In-Reply-To: <20130111140119.GC8436@order.stressinduktion.org>
On Fri, Jan 11, 2013 at 6:01 AM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> The report I meant was actually not referred in this bug report:
> http://article.gmane.org/gmane.linux.network/224832
>
> ENETDOWN was also observed via bridges.
Yes, I would have to think any report of ENETDOWN with ipv6 and
bridging is quite likely to be the same issue I hit.
- R.
^ permalink raw reply
* Re: [PATCH/RFC] ipv6: fib: Drop cached routes with dead neighbours on fib GC
From: Roland Dreier @ 2013-01-11 21:13 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <20130110.141847.265135906896223944.davem@davemloft.net>
On Thu, Jan 10, 2013 at 2:18 PM, David Miller <davem@davemloft.net> wrote:
> Another reason we must make ipv6 like ipv4, which looks up neighbours
> on demand at packet output time rather than caching them in the route
> entries.
Not sure I'm qualified to perform that level of surgery, but I'll take
a look at ipv4 and try to understand how that works.
In the meantime does it make sense to put a smaller bandaid in 3.8?
I'm pretty sure this is a regression (we never saw it with older
kernels), probably due to some part of the route cache improvements
you've been doing.
- R.
^ permalink raw reply
* RE: [PATCH net] qlge: remove NETIF_F_TSO6 flag
From: Jitendra Kalsaria @ 2013-01-11 21:48 UTC (permalink / raw)
To: Cong Wang, netdev; +Cc: Ron Mercer, Dept-Eng Linux Driver, David Miller
In-Reply-To: <1357894374-10767-1-git-send-email-amwang@redhat.com>
>From: Cong Wang [mailto:amwang@redhat.com]
>Sent: Friday, January 11, 2013 12:53 AM
>To: netdev
>Cc: Jitendra Kalsaria; Ron Mercer; Dept-Eng Linux Driver; David Miller; Cong Wang
>Subject: [PATCH net] qlge: remove NETIF_F_TSO6 flag
>
>It is werid that qlge driver supports NETIF_F_TSO6 but
>not NETIF_F_IPV6_CSUM. This also causes some kernel warning [1]
>when VLAN device setups on a qlge interface.
>
>I think the qlge hardware doesn't support NETIF_F_IPV6_CSUM,
>so we have to just remove the NETIF_F_TSO6 flag.
>
>After this patch, the TCP/IPv6 traffic becomes normal again,
>no kernel warnings any more.
>
>NOTE: I only tested it on 2.6.32 kernel, even if the upstream
>kernel could fix this automatically (it is hard to track NETIF*
>flags), removing it is also safe.
>
>1. https://bugzilla.redhat.com/show_bug.cgi?id=891839
>
>Cc: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
>Cc: Ron Mercer <ron.mercer@qlogic.com>
>Cc: linux-driver@qlogic.com
>Cc: David S. Miller <davem@davemloft.net>
>Signed-off-by: Cong Wang <amwang@redhat.com>
Thanks!
Acked-by: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
^ 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