* Re: [PATCH] ipv4: Disallow non-namespace aware protocols to register.
From: David Miller @ 2013-02-15 18:41 UTC (permalink / raw)
To: ebiederm; +Cc: netdev
In-Reply-To: <87pq028561.fsf@xmission.com>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Thu, 14 Feb 2013 22:25:26 -0800
> David Miller <davem@davemloft.net> writes:
>
>> All in-tree ipv4 protocol implementations are now namespace
>> aware. Therefore all the run-time checks are superfluous.
>>
>> Reject registry of any non-namespace aware ipv4 protocol.
>> Eventually we'll remove prot->netns_ok and this registry
>> time check as well.
>
> It has been a long time coming but this is very cool to see we have
> finally made all of ipv4 network namespace aware.
BTW, I took a look at ipv6 and unlike ipv4 there seems to be no sanity
checks or per-protocol booleans indicating proper netns support.
Is my interpretation right that ipv6 just assumes all registered
protocols are netns aware at this point?
If so that was definitely a bug, because things like l2tp have an
ipv6 component and were not fully netns aware until very recently.
^ permalink raw reply
* Re: [PATCH] NET/PHY: Eliminate the algorithm of forced ethernet speed reduction
From: David Miller @ 2013-02-15 18:54 UTC (permalink / raw)
To: kapranoff; +Cc: romieu, netdev, linux-kernel
In-Reply-To: <1360925459.4709.23.camel@kkk.nita.ru>
From: Kirill Kapranov <kapranoff@inbox.ru>
Date: Fri, 15 Feb 2013 14:50:59 +0400
> NET/PHY: Eliminate the forced speed reduction algorithm.
> In case of the fixed speed set up for NIC
> (e.g. ethtool -s eth0 autoneg off speed 100 duplex full)
> with ethernet cable plugged off, mentioned algorithm
> slows down NIC speed, so the further "hooking up" gives
> no result. AFAIK, this behaviour is not RFCs' recommended.
> Tested at 2.6.38.7, applicable up to for 3.0.4.
> Signed-off-by: Kirill Kapranov <kkk@nita.ru>,<kapranoff@inbox.ru>
This is formatted very unpleasantly, please put some care into
the formatting of your commit message, as if you were writing an
important letter to someone and you wanted it to look very nice.
^ permalink raw reply
* Re: [PATCH] net: fix infinite loop in __skb_recv_datagram()
From: David Miller @ 2013-02-15 18:56 UTC (permalink / raw)
To: hannes; +Cc: eric.dumazet, tt.rantala, netdev, davej, xemul
In-Reply-To: <20130215124141.GB20018@order.stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Fri, 15 Feb 2013 13:41:41 +0100
> On Tue, Feb 12, 2013 at 04:07:33PM -0500, David Miller wrote:
>> From: Eric Dumazet <eric.dumazet@gmail.com>
>> Date: Tue, 12 Feb 2013 08:16:53 -0800
>>
>> > From: Eric Dumazet <edumazet@google.com>
>> >
>> > Tommi was fuzzing with trinity and reported the following problem :
>> >
>> > commit 3f518bf745 (datagram: Add offset argument to __skb_recv_datagram)
>> > missed that a raw socket receive queue can contain skbs with no payload.
>> >
>> > We can loop in __skb_recv_datagram() with MSG_PEEK mode, because
>> > wait_for_packet() is not prepared to skip these skbs.
>> ...
>> > Reported-by: Tommi Rantala <tt.rantala@gmail.com>
>> > Tested-by: Tommi Rantala <tt.rantala@gmail.com>
>> > Signed-off-by: Eric Dumazet <edumazet@google.com>
>>
>> Applied, thanks.
>
> This issue got a CVE: http://seclists.org/oss-sec/2013/q1/310
> Perhaps it's something that should go to stable?
It's already queued up in my -stable queue.
^ permalink raw reply
* Re: [MacVLAN] failure to deliver reassembled IPv6 multicast traffic
From: Ben Greear @ 2013-02-15 19:07 UTC (permalink / raw)
To: Erik Hugne; +Cc: netdev, kaber, ataschner
In-Reply-To: <20130215170028.GG12219@eerihug-hybrid.ki.sw.ericsson.se>
On 02/15/2013 09:00 AM, Erik Hugne wrote:
> If macvlan's are configured on a device, IPv6 multicast
> traffic received on the underlying ethernet device is not
> delivered properly to higher layers. Large amounts of packets are lost, and
> the problem seems to get worse the more macvlans are defined
> on top of the device, up to the point where no traffic is delivered
> at all...
>
>
> Steps to reproduce (2 hosts required)
> On host 1, set up some macvlans:
> ip link add link eth0 name macvlan0 type macvlan mode bridge
> ip link add link eth0 name macvlan2 type macvlan mode bridge
> ip link add link eth0 name macvlan3 type macvlan mode bridge
> ip link set link dev macvlan0 up
> ip link set link dev macvlan2 up
> ip link set link dev macvlan3 up
>
> Start a server that binds to ff02::1 scoped to eth0
> ./server6 -sff02::1 -eeth0
>
>
> On host 2:
> ./client6 -dff02::1 -eeth0
>
>
> This seems to only occur for large (fragmented) IPv6 multicast traffic.
> If you bind to :: instead (-s:: on the server) and send to
> the linklocal address of Host1/eth0, packets are delivered just fine.
This has been around for a long time, maybe forever. Last time
we looked at this it did not appear there was an easy fix, something
to do with how UDP packets are re-assembled....
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 1/5 net-next v2] tg3: Add 57766 device support.
From: David Miller @ 2013-02-15 19:13 UTC (permalink / raw)
To: mchan; +Cc: netdev, nsujir
In-Reply-To: <1360888071-13108-1-git-send-email-mchan@broadcom.com>
All patches applied, using the updated versions of patches #1 and patch #2.
Can I ask kindly that you start to get into the habit of posting an
introductory "[PATCH 0/N] " email so that I can use it's contents
in the commit message of a merge commit and also reply to just that
one email to say I applied everything?
That would enhance the quality of your submissions and save me an
enormous amount of time.
Thanks.
^ permalink raw reply
* Re: [MacVLAN] failure to deliver reassembled IPv6 multicast traffic
From: Eric Dumazet @ 2013-02-15 19:18 UTC (permalink / raw)
To: Ben Greear; +Cc: Erik Hugne, netdev, kaber, ataschner
In-Reply-To: <511E8760.9070703@candelatech.com>
On Fri, 2013-02-15 at 11:07 -0800, Ben Greear wrote:
> This has been around for a long time, maybe forever. Last time
> we looked at this it did not appear there was an easy fix, something
> to do with how UDP packets are re-assembled....
This can be fixed the same way we did for IPv4
^ permalink raw reply
* Re: [MacVLAN] failure to deliver reassembled IPv6 multicast traffic
From: Ben Greear @ 2013-02-15 19:27 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Erik Hugne, netdev, kaber, ataschner
In-Reply-To: <1360955900.19353.22.camel@edumazet-glaptop>
On 02/15/2013 11:18 AM, Eric Dumazet wrote:
> On Fri, 2013-02-15 at 11:07 -0800, Ben Greear wrote:
>
>> This has been around for a long time, maybe forever. Last time
>> we looked at this it did not appear there was an easy fix, something
>> to do with how UDP packets are re-assembled....
>
> This can be fixed the same way we did for IPv4
For some reason I was thinking this wasn't fully fixed for IPv4, but
maybe it is..the bug in our internal tracker only mentions IPv6
as having issues...
We'll do some testing on IPv4 sometime soon to make sure, and can test
IPv6 patches as well...
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [MacVLAN] failure to deliver reassembled IPv6 multicast traffic
From: Eric Dumazet @ 2013-02-15 19:35 UTC (permalink / raw)
To: Ben Greear; +Cc: Erik Hugne, netdev, kaber, ataschner
In-Reply-To: <511E8C3D.5070603@candelatech.com>
On Fri, 2013-02-15 at 11:27 -0800, Ben Greear wrote:
> For some reason I was thinking this wasn't fully fixed for IPv4, but
> maybe it is..the bug in our internal tracker only mentions IPv6
> as having issues...
>
> We'll do some testing on IPv4 sometime soon to make sure, and can test
> IPv6 patches as well...
This worries me a bit, as I wrote this patch because you reported the
issue.
commit bc416d9768aa9a2e46eb11354a9c58399dafeb01
Author: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu Oct 6 10:28:31 2011 +0000
macvlan: handle fragmented multicast frames
Fragmented multicast frames are delivered to a single macvlan port,
because ip defrag logic considers other samples are redundant.
Implement a defrag step before trying to send the multicast frame.
Reported-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH v5 00/45] CPU hotplug: stop_machine()-free CPU hotplug
From: Srivatsa S. Bhat @ 2013-02-15 19:40 UTC (permalink / raw)
To: Vincent Guittot
Cc: paulmck, Russell King - ARM Linux, linux-doc, peterz, fweisbec,
linux-kernel, walken, mingo, linux-arch, xiaoguangrong, wangyun,
nikunj, linux-pm, Rusty Russell, rostedt, rjw, namhyung, tglx,
linux-arm-kernel, netdev, oleg, sbw, tj, akpm, linuxppc-dev
In-Reply-To: <CAKfTPtAo2hQTfBKTVUuLKgsGJ2ZLD0UTR3fH9UFuJwyFt4n__w@mail.gmail.com>
Hi Vincent,
On 02/15/2013 06:58 PM, Vincent Guittot wrote:
> Hi Srivatsa,
>
> I have run some tests with you branch (thanks Paul for the git tree)
> and you will find results below.
>
Thank you very much for testing this patchset!
> The tests condition are:
> - 5 CPUs system in 2 clusters
> - The test plugs/unplugs CPU2 and it increases the system load each 20
> plug/unplug sequence with either more cyclictests threads
> - The test is done with all CPUs online and with only CPU0 and CPU2
>
> The main conclusion is that there is no differences with and without
> your patches with my stress tests. I'm not sure that it was the
> expected results but the cpu_down is already quite low : 4-5ms in
> average
>
Atleast my patchset doesn't perform _worse_ than mainline, with respect
to cpu_down duration :-)
So, here is the analysis:
Stop-machine() doesn't really slow down CPU-down operation, if the rest
of the CPUs are mostly running in userspace all the time. Because, the
CPUs running userspace workloads cooperate very eagerly with the stop-machine
dance - they receive the resched IPI, and allow the per-cpu cpu-stopper
thread to monopolize the CPU, almost immediately.
The scenario where stop-machine() takes longer to take effect is when
most of the online CPUs are running in kernelspace, because, then the
probability that they call preempt_disable() frequently (and hence inhibit
stop-machine) is higher. That's why, in my tests, I ran genload from LTP
which generated a lot of system-time (system-time in 'top' indicates activity
in kernelspace). Hence my patchset showed significant improvement over
mainline in my tests.
However, your test is very useful too, if we measure a different parameter:
the latency impact on the workloads running on the system (cyclic test).
One other important aim of this patchset is to make hotplug as less intrusive
as possible, for other workloads running on the system. So if you measure
the cyclictest numbers, I would expect my patchset to show better numbers
than mainline, when you do cpu-hotplug in parallel (same test that you did).
Mainline would run stop-machine and hence interrupt the cyclic test tasks
too often. My patchset wouldn't do that, and hence cyclic test should
ideally show better numbers.
I'd really appreciate if you could try that out and let me know how it
goes.. :-) Thank you very much!
Regards,
Srivatsa S. Bhat
>
>
> On 12 February 2013 04:58, Srivatsa S. Bhat
> <srivatsa.bhat@linux.vnet.ibm.com> wrote:
>> On 02/12/2013 12:38 AM, Paul E. McKenney wrote:
>>> On Mon, Feb 11, 2013 at 05:53:41PM +0530, Srivatsa S. Bhat wrote:
>>>> On 02/11/2013 05:28 PM, Vincent Guittot wrote:
>>>>> On 8 February 2013 19:09, Srivatsa S. Bhat
>>>>> <srivatsa.bhat@linux.vnet.ibm.com> wrote:
>>>
>>> [ . . . ]
>>>
>>>>>> Adding Vincent to CC, who had previously evaluated the performance and
>>>>>> latency implications of CPU hotplug on ARM platforms, IIRC.
>>>>>>
>>>>>
>>>>> Hi Srivatsa,
>>>>>
>>>>> I can try to run some of our stress tests on your patches.
>>>>
>>>> Great!
>>>>
>>>>> Have you
>>>>> got a git tree that i can pull ?
>>>>>
>>>>
>>>> Unfortunately, no, none at the moment.. :-(
>>>
>>> You do need to create an externally visible git tree.
>>
>> Ok, I'll do that soon.
>>
>>> In the meantime,
>>> I have added your series at rcu/bhat.2013.01.21a on -rcu:
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
>>>
>>> This should appear soon on a kernel.org mirror near you. ;-)
>>>
>>
>> Thank you very much, Paul! :-)
>>
>> Regards,
>> Srivatsa S. Bhat
>>
^ permalink raw reply
* Re: [PATCH v2 1/1] drivers: net: davinci_cpdma: acknowledge interrupt properly
From: David Miller @ 2013-02-15 20:05 UTC (permalink / raw)
To: mugunthanvnm; +Cc: netdev, linux-arm-kernel, linux-omap
In-Reply-To: <1360866406-17261-1-git-send-email-mugunthanvnm@ti.com>
From: Mugunthan V N <mugunthanvnm@ti.com>
Date: Thu, 14 Feb 2013 23:56:46 +0530
> +enum {
> + CPDMA_EOI_RX_THRESH = 0,
> + CPDMA_EOI_RX,
> + CPDMA_EOI_TX,
> + CPDMA_EOI_MISC,
> +};
Do not use enumerations for hardware register values, which must be
exact, otherwise you are potentially going to succumb to the vagaries
of C language enumeration value assignment.
^ permalink raw reply
* Re: [PATCH] ipv4: Disallow non-namespace aware protocols to register.
From: Eric W. Biederman @ 2013-02-15 20:05 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20130215.134136.798843717749865061.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: ebiederm@xmission.com (Eric W. Biederman)
> Date: Thu, 14 Feb 2013 22:25:26 -0800
>
>> David Miller <davem@davemloft.net> writes:
>>
>>> All in-tree ipv4 protocol implementations are now namespace
>>> aware. Therefore all the run-time checks are superfluous.
>>>
>>> Reject registry of any non-namespace aware ipv4 protocol.
>>> Eventually we'll remove prot->netns_ok and this registry
>>> time check as well.
>>
>> It has been a long time coming but this is very cool to see we have
>> finally made all of ipv4 network namespace aware.
>
> BTW, I took a look at ipv6 and unlike ipv4 there seems to be no sanity
> checks or per-protocol booleans indicating proper netns support.
>
> Is my interpretation right that ipv6 just assumes all registered
> protocols are netns aware at this point?
It looks like when the ipv6 network namespace work was done work that
check was not added to the ipv6 code :( I skimmed through the history
and I don't see any signs that anything was every done with struct
inet6_protocol. Nor when I looked at the addition of netns support to
the ipv6 udp code were there any switches flipped.
> If so that was definitely a bug, because things like l2tp have an
> ipv6 component and were not fully netns aware until very recently.
Agreed it was a bug.
I have just read through all of the handlers registered with
inet6_add_protocol in my 3.8 development tree and it appears that
everything except l2tp has network namespace support. And l2tp is fixed
in net-next so we appear to be good now.
Eric
^ permalink raw reply
* Re: [PATCH v2 1/1] drivers: net: davinci_cpdma: acknowledge interrupt properly
From: David Miller @ 2013-02-15 20:05 UTC (permalink / raw)
To: mugunthanvnm; +Cc: netdev, linux-arm-kernel, linux-omap
In-Reply-To: <20130215.150506.499818568035818118.davem@davemloft.net>
Also please indicate, clearly, what tree your patch is targetted at.
^ permalink raw reply
* Re: [PATCH] ipv4: Disallow non-namespace aware protocols to register.
From: David Miller @ 2013-02-15 20:09 UTC (permalink / raw)
To: ebiederm; +Cc: netdev
In-Reply-To: <87a9r5tkap.fsf@xmission.com>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Fri, 15 Feb 2013 12:05:18 -0800
> David Miller <davem@davemloft.net> writes:
>
>> From: ebiederm@xmission.com (Eric W. Biederman)
>> Date: Thu, 14 Feb 2013 22:25:26 -0800
>>
>>> David Miller <davem@davemloft.net> writes:
>>>
>>>> All in-tree ipv4 protocol implementations are now namespace
>>>> aware. Therefore all the run-time checks are superfluous.
>>>>
>>>> Reject registry of any non-namespace aware ipv4 protocol.
>>>> Eventually we'll remove prot->netns_ok and this registry
>>>> time check as well.
>>>
>>> It has been a long time coming but this is very cool to see we have
>>> finally made all of ipv4 network namespace aware.
>>
>> BTW, I took a look at ipv6 and unlike ipv4 there seems to be no sanity
>> checks or per-protocol booleans indicating proper netns support.
>>
>> Is my interpretation right that ipv6 just assumes all registered
>> protocols are netns aware at this point?
>
> It looks like when the ipv6 network namespace work was done work that
> check was not added to the ipv6 code :( I skimmed through the history
> and I don't see any signs that anything was every done with struct
> inet6_protocol. Nor when I looked at the addition of netns support to
> the ipv6 udp code were there any switches flipped.
>
>> If so that was definitely a bug, because things like l2tp have an
>> ipv6 component and were not fully netns aware until very recently.
>
> Agreed it was a bug.
>
> I have just read through all of the handlers registered with
> inet6_add_protocol in my 3.8 development tree and it appears that
> everything except l2tp has network namespace support. And l2tp is fixed
> in net-next so we appear to be good now.
Thanks for confirming my analysis.
^ permalink raw reply
* RE: ixgbe: Regression, unsupported SFP+ modules on 10Gbit/s X520 NIC no longer work with allow_unsupported_sfp=1
From: Tantilov, Emil S @ 2013-02-15 20:14 UTC (permalink / raw)
To: Stefan Behte, netdev@vger.kernel.org
Cc: Skidmore, Donald C, Kirsher, Jeffrey T, Fujinaka, Todd,
Ronciak, John
In-Reply-To: <D76AF9B3DDF5FF49833AC0A1396549060314FBD8@s554.babiel.com>
Stefan,
I don't think this is a regression since the check you are bypassing with your patch has nothing to do with the unsupported SFP modules lock (this check is few lines below). The check you are trying to bypass is actually for supported 1gig SFP module types. Could you provide some additional information about your setup?
1. What is the SFP+ module you are using (make/model/type)?
2. What is the hw->phy.sfp_type set to (you can add a printk, or if you plug it in after load there should be a "detected SFP+" message in dmesg).
3. You said that you get the interfaces, but are they operational (link, pass traffic etc)?
4. Because you mentioned that this is a regression - was there a previous version of the driver that loads without the unsupported errors with this SFP module?
Thanks,
Emil
>-----Original Message-----
>From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
>Behalf Of Stefan Behte
>Sent: Thursday, February 14, 2013 4:58 PM
>To: netdev@vger.kernel.org
>Subject: ixgbe: Regression, unsupported SFP+ modules on 10Gbit/s X520 NIC
>no longer work with allow_unsupported_sfp=1
>
>Hello,
>
>I was told to send a mail, even though I had already opened
>https://bugzilla.kernel.org/show_bug.cgi?id=53901.
>
>Someone patched the ixgbe driver, and now non-intel SFPs do not work
>anymore, again. The issue of intel "lock-in" was discussed before here:
>http://marc.info/?l=e1000-devel&m=132697406314730&w=2
>
>A tested patch is attached.
>
>Here is what I do:
>
># modinfo ixgbe | grep parm
>parm: max_vfs:Maximum number of virtual functions to allocate per
>physical function - default is zero and maximum value is 63 (uint)
>parm: allow_unsupported_sfp:Allow unsupported and untested SFP+
>modules on 82599-based adapters (uint)
>parm: debug:Debug level (0=none,...,16=all) (int)
>
># modprobe -r ixgbe
># modprobe ixgbe allow_unsupported_sfp=0
># dmesg | grep ixgbe
>[13690.355090] ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver -
>version 3.9.15-k
>[13690.355092] ixgbe: Copyright (c) 1999-2012 Intel Corporation.
>[13690.373128] ixgbe 0000:02:00.0: failed to load because an unsupported
>SFP+ module type was detected.
>[13690.373177] ixgbe 0000:02:00.0: Reload the driver after installing a
>supported module.
>[13690.390987] ixgbe 0000:02:00.1: failed to load because an unsupported
>SFP+ module type was detected.
>[13690.391036] ixgbe 0000:02:00.1: Reload the driver after installing a
>supported module.
>
># modprobe -r ixgbe
># modprobe ixgbe allow_unsupported_sfp=1
># dmesg | grep ixgbe
>[13679.088849] dca service started, version 1.12.1
>[13679.091174] ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver -
>version 3.9.15-k
>[13679.091177] ixgbe: Copyright (c) 1999-2012 Intel Corporation.
>[13679.109194] ixgbe 0000:02:00.0: failed to load because an unsupported
>SFP+ module type was detected.
>[13679.109243] ixgbe 0000:02:00.0: Reload the driver after installing a
>supported module.
>[13679.127399] ixgbe 0000:02:00.1: failed to load because an unsupported
>SFP+ module type was detected.
>[13679.127450] ixgbe 0000:02:00.1: Reload the driver after installing a
>supported module.
>[13690.352712] dca service started, version 1.12.1
>
>
>With the patch:
>
># modprobe -r ixgbe
># modprobe ixgbe allow_unsupported_sfp=0
># dmesg | grep ixgbe
>[13907.870087] ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver -
>version 3.9.15-k
>[13907.870089] ixgbe: Copyright (c) 1999-2012 Intel Corporation.
>[13907.888106] ixgbe 0000:02:00.0: failed to load because an unsupported
>SFP+ module type was detected.
>[13907.888155] ixgbe 0000:02:00.0: Reload the driver after installing a
>supported module.
>[13907.906187] ixgbe 0000:02:00.1: failed to load because an unsupported
>SFP+ module type was detected.
>[13907.906237] ixgbe 0000:02:00.1: Reload the driver after installing a
>supported module.
>
>
># modprobe -r ixgbe
># modprobe ixgbe allow_unsupported_sfp=1
># dmesg | grep ixgbe
>[13914.534758] ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver -
>version3.9.15-k
>[13914.534761] ixgbe: Copyright (c) 1999-2012 Intel Corporation.
>[13914.552820] ixgbe 0000:02:00.0 (unregistered net_device): WARNING: Intel
>(R) Network Connections are quality tested using Intel (R) Ethernet Optics.
>Using untested modules is not supported and may cause unstable operation or
>damage to
>the module or the adapter. Intel Corporation is not responsible for any
>harm caused by using untested modules.
>[13917.741931] ixgbe 0000:02:00.0: irq 50 for MSI/MSI-X
>[13917.741938] ixgbe 0000:02:00.0: irq 51 for MSI/MSI-X
>[13917.741942] ixgbe 0000:02:00.0: irq 52 for MSI/MSI-X
>[13917.741951] ixgbe 0000:02:00.0: irq 53 for MSI/MSI-X
>[13917.741955] ixgbe 0000:02:00.0: irq 54 for MSI/MSI-X
>[13917.741960] ixgbe 0000:02:00.0: irq 55 for MSI/MSI-X
>[13917.741965] ixgbe 0000:02:00.0: irq 56 for MSI/MSI-X
>[13917.741969] ixgbe 0000:02:00.0: irq 57 for MSI/MSI-X
>[13917.741973] ixgbe 0000:02:00.0: irq 58 for MSI/MSI-X
>[13917.742002] ixgbe 0000:02:00.0: Multiqueue Enabled: Rx Queue count = 8,
>Tx Queue count = 8
>[13917.742126] ixgbe 0000:02:00.0: (PCI Express:5.0GT/s:Width x8)
>90:e2:ba:37:3b:18
>[13917.742207] ixgbe 0000:02:00.0: MAC: 2, PHY: 14, SFP+: 65535, PBA No:
>E68793-005
>[13917.743461] ixgbe 0000:02:00.0: Intel(R) 10 Gigabit Network Connection
>[13917.761578] ixgbe 0000:02:00.1 (unregistered net_device): WARNING: Intel
>(R) Network Connections are quality tested using Intel (R) Ethernet Optics.
>Using untested modules is not supported and may cause unstable operation or
>damage to the module or the adapter. Intel Corporation is not responsible
>for any harm caused by using untested modules.
>[13920.948726] ixgbe 0000:02:00.1: irq 59 for MSI/MSI-X
>[13920.948737] ixgbe 0000:02:00.1: irq 60 for MSI/MSI-X
>[13920.948742] ixgbe 0000:02:00.1: irq 61 for MSI/MSI-X
>[13920.948746] ixgbe 0000:02:00.1: irq 62 for MSI/MSI-X
>[13920.948751] ixgbe 0000:02:00.1: irq 63 for MSI/MSI-X
>[13920.948757] ixgbe 0000:02:00.1: irq 64 for MSI/MSI-X
>[13920.948761] ixgbe 0000:02:00.1: irq 65 for MSI/MSI-X
>[13920.948767] ixgbe 0000:02:00.1: irq 66 for MSI/MSI-X
>[13920.948774] ixgbe 0000:02:00.1: irq 67 for MSI/MSI-X
>[13920.948803] ixgbe 0000:02:00.1: Multiqueue Enabled: Rx Queue count = 8,
>Tx Queue count = 8
>[13920.948927] ixgbe 0000:02:00.1: (PCI Express:5.0GT/s:Width x8)
>90:e2:ba:37:3b:19
>[13920.949008] ixgbe 0000:02:00.1: MAC: 2, PHY: 14, SFP+: 65535, PBA No:
>E68793-005
>[13920.950237] ixgbe 0000:02:00.1: Intel(R) 10 Gigabit Network Connection
>
>And then I get two nice Interfaces. Please apply. :)
>
>
>Best regards,
>
>Stefan Behte
>
>Babiel GmbH
>Moskauer Strasse 27
>D-40227 Düsseldorf
>
>Tel: 0211-179349 0
>Fax: 0211-179349 29
>E-Mail: S.Behte@babiel.com
>Internet: http://www.babiel.com
>
>Geschäftsführer: Georg Babiel, Dr. Rainer Babiel, Harald Babiel
>Amtsgericht Düsseldorf HRB 38633
>
>~~~~~~~~~~~~~~ DISCLAIMER ~~~~~~~~~~~~~~~
>
>The information transmitted in this electronic mail message may contain
>confidential and or privileged materials. Any review, retransmission,
>dissemination or other use of or taking of any action in reliance upon,
>this information by persons or entities other than the intended recipient
>is prohibited. If you receive such e-mails in error, please contact the
>sender and delete the material from any computer.
^ permalink raw reply
* Re: [PATCH net-next 0/3] v3 GRE: TCP segmentation offload
From: David Miller @ 2013-02-15 20:18 UTC (permalink / raw)
To: pshelar; +Cc: netdev, edumazet, jesse, bhutchings, mirqus
In-Reply-To: <1360871081-1987-1-git-send-email-pshelar@nicira.com>
From: Pravin B Shelar <pshelar@nicira.com>
Date: Thu, 14 Feb 2013 11:44:41 -0800
> Following patches add TCP segmentation offload to GRE. These
> patches shows 20-25% performance improvement in netperf single
> process TCP_STREAM test on 10G network.
>
> Pravin B Shelar (3):
> net: Add skb_unclone() helper function.
> net: factor out skb_mac_gso_segment() from skb_gso_segment()
> GRE: Add TCP segmentation offload for GRE
All applied, incorporating the suggestions/fixes from Eric. Specifically,
using skb_reset_mac_len() in patch #2 and computing pkt_len before ip_local_out()
in patch #3.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 1/1] drivers: net: davinci_cpdma: acknowledge interrupt properly
From: Joe Perches @ 2013-02-15 20:18 UTC (permalink / raw)
To: David Miller; +Cc: mugunthanvnm, netdev, linux-arm-kernel, linux-omap
In-Reply-To: <20130215.150506.499818568035818118.davem@davemloft.net>
On Fri, 2013-02-15 at 15:05 -0500, David Miller wrote:
> From: Mugunthan V N <mugunthanvnm@ti.com>
> Date: Thu, 14 Feb 2013 23:56:46 +0530
>
> > +enum {
> > + CPDMA_EOI_RX_THRESH = 0,
> > + CPDMA_EOI_RX,
> > + CPDMA_EOI_TX,
> > + CPDMA_EOI_MISC,
> > +};
>
> Do not use enumerations for hardware register values, which must be
> exact, otherwise you are potentially going to succumb to the vagaries
> of C language enumeration value assignment.
Vagaries?
In what way is c enumeration (6.7.2.2) vague?
char vs int? Isn't smaller mostly better?
Concern about possible future reordering given an
insertion or deletion might be the only consideration
I could imagine.
^ permalink raw reply
* Re: [PATCH v2 1/1] drivers: net: davinci_cpdma: acknowledge interrupt properly
From: David Miller @ 2013-02-15 20:20 UTC (permalink / raw)
To: joe; +Cc: mugunthanvnm, netdev, linux-arm-kernel, linux-omap
In-Reply-To: <1360959539.21068.5.camel@joe-AO722>
From: Joe Perches <joe@perches.com>
Date: Fri, 15 Feb 2013 12:18:59 -0800
> On Fri, 2013-02-15 at 15:05 -0500, David Miller wrote:
>> From: Mugunthan V N <mugunthanvnm@ti.com>
>> Date: Thu, 14 Feb 2013 23:56:46 +0530
>>
>> > +enum {
>> > + CPDMA_EOI_RX_THRESH = 0,
>> > + CPDMA_EOI_RX,
>> > + CPDMA_EOI_TX,
>> > + CPDMA_EOI_MISC,
>> > +};
>>
>> Do not use enumerations for hardware register values, which must be
>> exact, otherwise you are potentially going to succumb to the vagaries
>> of C language enumeration value assignment.
>
> Vagaries?
>
> In what way is c enumeration (6.7.2.2) vague?
> char vs int? Isn't smaller mostly better?
>
> Concern about possible future reordering given an
> insertion or deletion might be the only consideration
> I could imagine.
Right. That's why you should use explicit CPP defines for
register offsets and values.
^ permalink raw reply
* [PATCH iproute 0/3] Bridge VLAN support
From: Vlad Yasevich @ 2013-02-15 20:21 UTC (permalink / raw)
To: netdev; +Cc: shemminger
This series adds VLAN configuration to the bridge command. With this
series, one can specify vlans in FDB entries as well as to configure
VLAN configuration on the bridge ports.
Vlad Yasevich (3):
bridge: Add vlan support to fdb entries
bridge: Add vlan configuration support
bridge: Update bridge man pages to include vlan command
bridge/Makefile | 2 +-
bridge/br_common.h | 1 +
bridge/bridge.c | 3 +-
bridge/fdb.c | 16 +++-
bridge/vlan.c | 220 +++++++++++++++++++++++++++++++++++++++++++++
include/libnetlink.h | 2 +
include/linux/if_bridge.h | 10 ++
include/linux/neighbour.h | 1 +
include/linux/rtnetlink.h | 1 +
lib/libnetlink.c | 28 ++++++-
man/man8/bridge.8 | 73 +++++++++++++++-
11 files changed, 352 insertions(+), 5 deletions(-)
create mode 100644 bridge/vlan.c
--
1.7.7.6
^ permalink raw reply
* [PATCH iproute 1/3] bridge: Add vlan support to fdb entries
From: Vlad Yasevich @ 2013-02-15 20:21 UTC (permalink / raw)
To: netdev; +Cc: shemminger
In-Reply-To: <1360959712-7977-1-git-send-email-vyasevic@redhat.com>
Provide the ability to set and show vlans on FDB entries.
Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
---
bridge/fdb.c | 16 +++++++++++++++-
include/linux/neighbour.h | 1 +
2 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/bridge/fdb.c b/bridge/fdb.c
index 4ca4861..447045e 100644
--- a/bridge/fdb.c
+++ b/bridge/fdb.c
@@ -29,7 +29,7 @@ int filter_index;
static void usage(void)
{
- fprintf(stderr, "Usage: bridge fdb { add | del } ADDR dev DEV {self|master} [ temp ] [ dst IPADDR]\n");
+ fprintf(stderr, "Usage: bridge fdb { add | del } ADDR dev DEV {self|master} [ temp ] [ dst IPADDR] [ vlan VID ]\n");
fprintf(stderr, " bridge fdb {show} [ dev DEV ]\n");
exit(-1);
}
@@ -107,6 +107,11 @@ int print_fdb(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
abuf, sizeof(abuf)));
}
+ if (tb[NDA_VLAN]) {
+ __u16 vid = rta_getattr_u16(tb[NDA_VLAN]);
+ fprintf(fp, "vlan %hu ", vid);
+ }
+
if (show_stats && tb[NDA_CACHEINFO]) {
struct nda_cacheinfo *ci = RTA_DATA(tb[NDA_CACHEINFO]);
int hz = get_user_hz();
@@ -171,6 +176,7 @@ static int fdb_modify(int cmd, int flags, int argc, char **argv)
char abuf[ETH_ALEN];
int dst_ok = 0;
inet_prefix dst;
+ short vid = -1;
memset(&req, 0, sizeof(req));
@@ -199,6 +205,11 @@ static int fdb_modify(int cmd, int flags, int argc, char **argv)
req.ndm.ndm_state |= NUD_PERMANENT;
} else if (matches(*argv, "temp") == 0) {
req.ndm.ndm_state |= NUD_REACHABLE;
+ } else if (matches(*argv, "vlan") == 0) {
+ if (vid >= 0)
+ duparg2("vlan", *argv);
+ NEXT_ARG();
+ vid = atoi(*argv);
} else {
if (strcmp(*argv, "to") == 0) {
NEXT_ARG();
@@ -236,6 +247,9 @@ static int fdb_modify(int cmd, int flags, int argc, char **argv)
if (dst_ok)
addattr_l(&req.n, sizeof(req), NDA_DST, &dst.data, dst.bytelen);
+ if (vid >= 0)
+ addattr16(&req.n, sizeof(req), NDA_VLAN, vid);
+
req.ndm.ndm_ifindex = ll_name_to_index(d);
if (req.ndm.ndm_ifindex == 0) {
fprintf(stderr, "Cannot find device \"%s\"\n", d);
diff --git a/include/linux/neighbour.h b/include/linux/neighbour.h
index 275e5d6..adb068c 100644
--- a/include/linux/neighbour.h
+++ b/include/linux/neighbour.h
@@ -20,6 +20,7 @@ enum {
NDA_LLADDR,
NDA_CACHEINFO,
NDA_PROBES,
+ NDA_VLAN,
__NDA_MAX
};
--
1.7.7.6
^ permalink raw reply related
* [PATCH iproute 2/3] bridge: Add vlan configuration support
From: Vlad Yasevich @ 2013-02-15 20:21 UTC (permalink / raw)
To: netdev; +Cc: shemminger
In-Reply-To: <1360959712-7977-1-git-send-email-vyasevic@redhat.com>
Recent kernel patches added support for VLAN filtering on the bridge.
This functionality allows one to turn a basic bridge into a VLAN bridge,
where VLANs dicatate packet forwarding and header transformation.
To configure the VLANs on the bridge and its ports a new command is
added to the 'bridge' utility.
# bridge vlan add dev eth0 vid 10 pvid untagged brdev
# bridge vlan add
# bridge vlan delete dev eth0 vid 10
# bridge vlan show
This command supports the following flags:
master - peform the operation on the software bridge device. This is
the default behavior.
self - perform the operation on the hardware associated with the port.
This flag is required when the device is the bridge device and
the configuration is desired on the bridge device itself (not
one of the ports).
pvid - Set the PVID (port vlan id) for a given port. Any untagged
frames arriving on the port will be assigned to this vlan.
untagged - Sets the egress policy of for a given vlan. Default port
egress policy is tagged. Set this flag if you wish traffic
associated with this VLAN to exit the port untagged.
Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
---
bridge/Makefile | 2 +-
bridge/br_common.h | 1 +
bridge/bridge.c | 3 +-
bridge/vlan.c | 220 +++++++++++++++++++++++++++++++++++++++++++++
include/libnetlink.h | 2 +
include/linux/if_bridge.h | 10 ++
include/linux/rtnetlink.h | 1 +
lib/libnetlink.c | 28 ++++++-
8 files changed, 264 insertions(+), 3 deletions(-)
create mode 100644 bridge/vlan.c
diff --git a/bridge/Makefile b/bridge/Makefile
index 67aceb4..1fb8320 100644
--- a/bridge/Makefile
+++ b/bridge/Makefile
@@ -1,4 +1,4 @@
-BROBJ = bridge.o fdb.o monitor.o link.o mdb.o
+BROBJ = bridge.o fdb.o monitor.o link.o mdb.o vlan.o
include ../Config
diff --git a/bridge/br_common.h b/bridge/br_common.h
index 10f6ce9..8764563 100644
--- a/bridge/br_common.h
+++ b/bridge/br_common.h
@@ -9,6 +9,7 @@ extern int print_mdb(const struct sockaddr_nl *who,
extern int do_fdb(int argc, char **argv);
extern int do_mdb(int argc, char **argv);
extern int do_monitor(int argc, char **argv);
+extern int do_vlan(int argc, char **argv);
extern int preferred_family;
extern int show_stats;
diff --git a/bridge/bridge.c b/bridge/bridge.c
index 1d59a1e..06b7a54 100644
--- a/bridge/bridge.c
+++ b/bridge/bridge.c
@@ -27,7 +27,7 @@ static void usage(void)
{
fprintf(stderr,
"Usage: bridge [ OPTIONS ] OBJECT { COMMAND | help }\n"
-"where OBJECT := { fdb | mdb | monitor }\n"
+"where OBJECT := { fdb | mdb | vlan | monitor }\n"
" OPTIONS := { -V[ersion] | -s[tatistics] | -d[etails]\n" );
exit(-1);
}
@@ -44,6 +44,7 @@ static const struct cmd {
} cmds[] = {
{ "fdb", do_fdb },
{ "mdb", do_mdb },
+ { "vlan", do_vlan },
{ "monitor", do_monitor },
{ "help", do_help },
{ 0 }
diff --git a/bridge/vlan.c b/bridge/vlan.c
new file mode 100644
index 0000000..83c4088
--- /dev/null
+++ b/bridge/vlan.c
@@ -0,0 +1,220 @@
+#include <stdio.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <fcntl.h>
+#include <sys/socket.h>
+#include <net/if.h>
+#include <netinet/in.h>
+#include <linux/if_bridge.h>
+#include <linux/if_ether.h>
+#include <string.h>
+
+#include "libnetlink.h"
+#include "br_common.h"
+#include "utils.h"
+
+int filter_index;
+
+static void usage(void)
+{
+ fprintf(stderr, "Usage: bridge vlan { add | del } vid VLAN_ID dev DEV [ pvid] [ untagged ]\n");
+ fprintf(stderr, " [ self ] [ master ]\n");
+ fprintf(stderr, " bridge vlan { show } [ dev DEV ]\n");
+ exit(-1);
+}
+
+static int vlan_modify(int cmd, int argc, char **argv)
+{
+ struct {
+ struct nlmsghdr n;
+ struct ifinfomsg ifm;
+ char buf[1024];
+ } req;
+ char *d = NULL;
+ short vid = -1;
+ struct rtattr *afspec;
+ struct bridge_vlan_info vinfo;
+ unsigned short flags = 0;
+
+ memset(&vinfo, 0, sizeof(vinfo));
+ memset(&req, 0, sizeof(req));
+
+ req.n.nlmsg_len = NLMSG_LENGTH(sizeof(struct ifinfomsg));
+ req.n.nlmsg_flags = NLM_F_REQUEST;
+ req.n.nlmsg_type = cmd;
+ req.ifm.ifi_family = PF_BRIDGE;
+
+ while (argc > 0) {
+ if (strcmp(*argv, "dev") == 0) {
+ NEXT_ARG();
+ d = *argv;
+ } else if (strcmp(*argv, "vid") == 0) {
+ NEXT_ARG();
+ vid = atoi(*argv);
+ } else if (strcmp(*argv, "self") == 0) {
+ flags |= BRIDGE_FLAGS_SELF;
+ } else if (strcmp(*argv, "master") == 0) {
+ flags |= BRIDGE_FLAGS_MASTER;
+ } else if (strcmp(*argv, "pvid") == 0) {
+ vinfo.flags |= BRIDGE_VLAN_INFO_PVID;
+ } else if (strcmp(*argv, "untagged") == 0) {
+ vinfo.flags |= BRIDGE_VLAN_INFO_UNTAGGED;
+ } else {
+ if (matches(*argv, "help") == 0) {
+ NEXT_ARG();
+ }
+ }
+ argc--; argv++;
+ }
+
+ if (d == NULL || vid == -1) {
+ fprintf(stderr, "Device and VLAN ID are required arguments.\n");
+ exit(-1);
+ }
+
+ req.ifm.ifi_index = ll_name_to_index(d);
+ if (req.ifm.ifi_index == 0) {
+ fprintf(stderr, "Cannot find bridge device \"%s\"\n", d);
+ return -1;
+ }
+
+ if (vid >= 4096) {
+ fprintf(stderr, "Invalid VLAN ID \"%hu\"\n", vid);
+ return -1;
+ }
+
+ vinfo.vid = vid;
+
+ afspec = addattr_nest(&req.n, sizeof(req), IFLA_AF_SPEC);
+
+ if (flags)
+ addattr16(&req.n, sizeof(req), IFLA_BRIDGE_FLAGS, flags);
+
+ addattr_l(&req.n, sizeof(req), IFLA_BRIDGE_VLAN_INFO, &vinfo,
+ sizeof(vinfo));
+
+ addattr_nest_end(&req.n, afspec);
+
+ if (rtnl_talk(&rth, &req.n, 0, 0, NULL) < 0)
+ exit(2);
+
+ return 0;
+}
+
+static int print_vlan(const struct sockaddr_nl *who,
+ struct nlmsghdr *n,
+ void *arg)
+{
+ FILE *fp = arg;
+ struct ifinfomsg *ifm = NLMSG_DATA(n);
+ int len = n->nlmsg_len;
+ struct rtattr * tb[IFLA_MAX+1];
+
+ if (n->nlmsg_type != RTM_NEWLINK) {
+ fprintf(stderr, "Not RTM_NEWLINK: %08x %08x %08x\n",
+ n->nlmsg_len, n->nlmsg_type, n->nlmsg_flags);
+ return 0;
+ }
+
+ len -= NLMSG_LENGTH(sizeof(*ifm));
+ if (len < 0) {
+ fprintf(stderr, "BUG: wrong nlmsg len %d\n", len);
+ return -1;
+ }
+
+ if (ifm->ifi_family != AF_BRIDGE)
+ return 0;
+
+ if (filter_index && filter_index != ifm->ifi_index)
+ return 0;
+
+ parse_rtattr(tb, IFLA_MAX, IFLA_RTA(ifm), len);
+
+ /* if AF_SPEC isn't there, vlan table is not preset for this port */
+ if (!tb[IFLA_AF_SPEC]) {
+ fprintf(fp, "%s\tNone\n", ll_index_to_name(ifm->ifi_index));
+ return 0;
+ } else {
+ struct rtattr *i, *list = tb[IFLA_AF_SPEC];
+ int rem = RTA_PAYLOAD(list);
+
+ fprintf(fp, "%s", ll_index_to_name(ifm->ifi_index));
+ for (i = RTA_DATA(list); RTA_OK(i, rem); i = RTA_NEXT(i, rem)) {
+ struct bridge_vlan_info *vinfo;
+
+ if (i->rta_type != IFLA_BRIDGE_VLAN_INFO)
+ continue;
+
+ vinfo = RTA_DATA(i);
+ fprintf(fp, "\t %hu", vinfo->vid);
+ if (vinfo->flags & BRIDGE_VLAN_INFO_PVID)
+ fprintf(fp, " PVID");
+ if (vinfo->flags & BRIDGE_VLAN_INFO_UNTAGGED)
+ fprintf(fp, " Egress Untagged");
+ fprintf(fp, "\n");
+ }
+ }
+ fprintf(fp, "\n");
+ fflush(fp);
+ return 0;
+}
+
+static int vlan_show(int argc, char **argv)
+{
+ char *filter_dev = NULL;
+
+ while (argc > 0) {
+ if (strcmp(*argv, "dev") == 0) {
+ NEXT_ARG();
+ if (filter_dev)
+ duparg("dev", *argv);
+ filter_dev = *argv;
+ }
+ argc--; argv++;
+ }
+
+ if (filter_dev) {
+ if ((filter_index = if_nametoindex(filter_dev)) == 0) {
+ fprintf(stderr, "Cannot find device \"%s\"\n",
+ filter_dev);
+ return -1;
+ }
+ }
+
+ if (rtnl_wilddump_req_filter(&rth, PF_BRIDGE, RTM_GETLINK,
+ RTEXT_FILTER_BRVLAN) < 0) {
+ perror("Cannont send dump request");
+ exit(1);
+ }
+
+ printf("port\tvlan ids\n");
+ if (rtnl_dump_filter(&rth, print_vlan, stdout) < 0) {
+ fprintf(stderr, "Dump ternminated\n");
+ exit(1);
+ }
+
+ return 0;
+}
+
+
+int do_vlan(int argc, char **argv)
+{
+ ll_init_map(&rth);
+
+ if (argc > 0) {
+ if (matches(*argv, "add") == 0)
+ return vlan_modify(RTM_SETLINK, argc-1, argv+1);
+ if (matches(*argv, "delete") == 0)
+ return vlan_modify(RTM_DELLINK, argc-1, argv+1);
+ if (matches(*argv, "show") == 0 ||
+ matches(*argv, "lst") == 0 ||
+ matches(*argv, "list") == 0)
+ return vlan_show(argc-1, argv+1);
+ if (matches(*argv, "help") == 0)
+ usage();
+ } else
+ return vlan_show(0, NULL);
+
+ fprintf(stderr, "Command \"%s\" is unknown, try \"bridge fdb help\".\n", *argv);
+ exit(-1);
+}
diff --git a/include/libnetlink.h b/include/libnetlink.h
index 41e6ed1..8d15ee5 100644
--- a/include/libnetlink.h
+++ b/include/libnetlink.h
@@ -26,6 +26,8 @@ extern int rtnl_open(struct rtnl_handle *rth, unsigned subscriptions);
extern int rtnl_open_byproto(struct rtnl_handle *rth, unsigned subscriptions, int protocol);
extern void rtnl_close(struct rtnl_handle *rth);
extern int rtnl_wilddump_request(struct rtnl_handle *rth, int fam, int type);
+extern int rtnl_wilddump_req_filter(struct rtnl_handle *rth, int fam, int type,
+ __u32 filt_mask);
extern int rtnl_dump_request(struct rtnl_handle *rth, int type, void *req, int len);
typedef int (*rtnl_filter_t)(const struct sockaddr_nl *,
diff --git a/include/linux/if_bridge.h b/include/linux/if_bridge.h
index aac8b8c..7a44a27 100644
--- a/include/linux/if_bridge.h
+++ b/include/linux/if_bridge.h
@@ -113,10 +113,20 @@ struct __fdb_entry {
enum {
IFLA_BRIDGE_FLAGS,
IFLA_BRIDGE_MODE,
+ IFLA_BRIDGE_VLAN_INFO,
__IFLA_BRIDGE_MAX,
};
#define IFLA_BRIDGE_MAX (__IFLA_BRIDGE_MAX - 1)
+#define BRIDGE_VLAN_INFO_MASTER (1<<0)
+#define BRIDGE_VLAN_INFO_PVID (1<<1)
+#define BRIDGE_VLAN_INFO_UNTAGGED (1<<2)
+
+struct bridge_vlan_info {
+ __u16 flags;
+ __u16 vid;
+};
+
/* Bridge multicast database attributes
* [MDBA_MDB] = {
* [MDBA_MDB_ENTRY] = {
diff --git a/include/linux/rtnetlink.h b/include/linux/rtnetlink.h
index 87452b4..93370bd 100644
--- a/include/linux/rtnetlink.h
+++ b/include/linux/rtnetlink.h
@@ -628,6 +628,7 @@ struct tcamsg {
/* New extended info filters for IFLA_EXT_MASK */
#define RTEXT_FILTER_VF (1 << 0)
+#define RTEXT_FILTER_BRVLAN (1 << 1)
/* End of information exported to user level */
diff --git a/lib/libnetlink.c b/lib/libnetlink.c
index 8e8c8b9..77b7128 100644
--- a/lib/libnetlink.c
+++ b/lib/libnetlink.c
@@ -109,7 +109,33 @@ int rtnl_wilddump_request(struct rtnl_handle *rth, int family, int type)
req.ext_req.rta_type = IFLA_EXT_MASK;
req.ext_req.rta_len = RTA_LENGTH(sizeof(__u32));
- req.ext_filter_mask = RTEXT_FILTER_VF;
+ req.ext_filter_mask = RTEXT_FILTER_VF | RTEXT_FILTER_BRVLAN;
+
+ return send(rth->fd, (void*)&req, sizeof(req), 0);
+}
+
+int rtnl_wilddump_req_filter(struct rtnl_handle *rth, int family, int type,
+ __u32 filt_mask)
+{
+ struct {
+ struct nlmsghdr nlh;
+ struct rtgenmsg g;
+ __u16 align_rta; /* attribute has to be 32bit aligned */
+ struct rtattr ext_req;
+ __u32 ext_filter_mask;
+ } req;
+
+ memset(&req, 0, sizeof(req));
+ req.nlh.nlmsg_len = sizeof(req);
+ req.nlh.nlmsg_type = type;
+ req.nlh.nlmsg_flags = NLM_F_DUMP|NLM_F_REQUEST;
+ req.nlh.nlmsg_pid = 0;
+ req.nlh.nlmsg_seq = rth->dump = ++rth->seq;
+ req.g.rtgen_family = family;
+
+ req.ext_req.rta_type = IFLA_EXT_MASK;
+ req.ext_req.rta_len = RTA_LENGTH(sizeof(__u32));
+ req.ext_filter_mask = filt_mask;
return send(rth->fd, (void*)&req, sizeof(req), 0);
}
--
1.7.7.6
^ permalink raw reply related
* [PATCH iproute 3/3] bridge: Update bridge man pages to include vlan command
From: Vlad Yasevich @ 2013-02-15 20:21 UTC (permalink / raw)
To: netdev; +Cc: shemminger
In-Reply-To: <1360959712-7977-1-git-send-email-vyasevic@redhat.com>
Add the vlan command documentation to bridge man page.
Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
---
man/man8/bridge.8 | 73 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 72 insertions(+), 1 deletions(-)
diff --git a/man/man8/bridge.8 b/man/man8/bridge.8
index fd91618..d34e3cf 100644
--- a/man/man8/bridge.8
+++ b/man/man8/bridge.8
@@ -13,7 +13,7 @@ bridge \- show / manipulate bridge addresses and devices
.ti -8
.IR OBJECT " := { "
-.BR fdb " | " monitor " }"
+.BR fdb " | " vlan " | " monitor " }"
.sp
.ti -8
@@ -35,6 +35,20 @@ bridge \- show / manipulate bridge addresses and devices
.IR DEV " ]"
.ti -8
+.BR "bridge vlan" " { " add " | " del " } "
+.B dev
+.IR DEV
+.B vid
+.IR VID " [ "
+.BR pvid " ] [ " untagged " ] [ "
+.BR self " ] [ " master " ] "
+
+.ti -8
+.BR "bridge vlan" " [ " show " ] [ "
+.B dev
+.IR DEV " ]"
+
+.ti -8
.BR "bridge monitor" " [ " all " | " neigh " | " link " ]"
.SH OPTIONS
@@ -61,6 +75,10 @@ As a rule, the information is statistics or some time values.
.B fdb
- Forwarding Database entry.
+.TP
+.B vlan
+- VLAN filter list.
+
.SS
.I COMMAND
@@ -143,6 +161,59 @@ With the
option, the command becomes verbose. It prints out the last updated
and last used time for each entry.
+.SH bridge vlan - VLAN filter list
+
+.B vlan
+objects contain known VLAN IDs for a link.
+
+.P
+The corresponding commands display vlan filter entries, add new entries,
+and delete old ones.
+
+.SS bridge vlan add - add a new vlan filter entry
+
+This command creates a new vlan filter entry.
+
+.TP
+.BI dev " NAME"
+the interface with which this vlan is associated.
+
+.TP
+.BI vid " VID"
+the VLAN ID that identifies the vlan.
+
+.TP
+.BI pvid
+the vlan specified is to be considered a PVID at ingress.
+Any untagged frames will be assigned to this VLAN.
+
+.TP
+.BI untagged
+the vlan specified is to be treated as untagged on egress.
+
+.TP
+.BI self
+the vlan is configured on the specified physical device. Required if the
+device is the bridge device.
+
+.TP
+.BI master
+the vlan is configured on the sofware bridge (default).
+
+.SS bridge vlan delete - delete a forwarding database entry
+This command removes an existing fdb entry.
+
+.PP
+The arguments are the same as with
+.BR "bridge vlan add".
+The
+.BR "pvid " and " untagged"
+flags are ignored.
+
+.SS bridge vlan show - list vlan configuration.
+
+This command displays the current VLAN filter table.
+
.SH bridge monitor - state monitoring
The
--
1.7.7.6
^ permalink raw reply related
* Re: [net-next v2 00/10][pull request] Intel Wired LAN Driver Updates 2013.02.15
From: David Miller @ 2013-02-15 20:33 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann
In-Reply-To: <1360922649-3388-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 15 Feb 2013 02:03:59 -0800
> This series contains updates to igb and ixgbe. Most of the changes
> are against igb, except for one patch against ixgbe.
>
> There are 3 igb fixes from Carolyn which were reported by Dan
> Carpenter which resolve issues found in the get_i2c_client(). Alex
> does some cleanup of the igb driver to match similar functionality
> in ixgbe on transmit. Alex also makes it so that we can enable the use
> of build_skb for cases where jumbo frames are disabled. The advantage
> to this is that we do not have to perform a memcpy to populate the header
> and as a result we see a significant performance improvement.
>
> Akeem provides 4 patches to initialize function pointers and do a
> re-factoring of the function pointers in igb_get_variants() to assist
> with driver debugging.
>
> The ixgbe patch comes from Emil to reshuffle the switch/case structure
> of the flag assignment to allow for the flags to be set for each MAC
> type separately. This is needed for new hardware that does not have feature
> parity with older hardware.
>
> v2: updated patches 4 & 5 based on feedback from Ben Hutchings and Eric
> Dumazet
>
> The following are changes since commit 9754e293491e3a4e6c1ac020d25140b1ed3d9cd2:
> net: Don't write to current task flags on every packet received.
> and are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next master
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH (net.git)] stmmac: fix the parsing of the eee_timer parameter
From: David Miller @ 2013-02-15 20:34 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev
In-Reply-To: <1360918813-25805-1-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
Date: Fri, 15 Feb 2013 10:00:13 +0100
> This pacth fixes the parsing of the eee_timer driver parameter.
>
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ieee802154: at86rf230: Remove empty suspend/resume callbacks
From: David Miller @ 2013-02-15 20:35 UTC (permalink / raw)
To: lars; +Cc: alex.bluesman.smirnov, dbaryshkov, linux-zigbee-devel, netdev
In-Reply-To: <1360933409-2529-1-git-send-email-lars@metafoo.de>
From: Lars-Peter Clausen <lars@metafoo.de>
Date: Fri, 15 Feb 2013 14:03:29 +0100
> There is no need to implement empty suspend/resume callbacks if there is nothing
> to do during suspend/resume. The drivers will behave the same with no callbacks
> or empty callbacks during suspend/resume.
>
> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: use skb_reset_mac_len() in dev_gro_receive()
From: David Miller @ 2013-02-15 20:37 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1360899108.6884.77.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 14 Feb 2013 19:31:48 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> We no longer need to use mac_len, lets cleanup things.
>
> Signed-off-by: Eric Dumazet <edumazet@google.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