* [PATCH 0/10] ipv4: Fetch values from flow key not route.
From: David Miller @ 2011-04-29 17:26 UTC (permalink / raw)
To: netdev
Here is the first set of simplifications that are possible now that
output route lookup will update the flow lookup key the caller passes
in.
Signed-off-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* [PATCH] net: fix rtnl even race in register_netdevice()
From: Kalle Valo @ 2011-04-29 17:26 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA; +Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA
From: Kalle Valo <kalle.valo-DlyHzToyqoxBDgjK7y7TUQ@public.gmane.org>
There's a race in register_netdevice so that the rtnl event is sent before
the device is actually ready. This was visible with flimflam, chrome os
connection manager:
00:21:35 roska flimflamd[2598]: src/udev.c:add_net_device()
00:21:35 roska flimflamd[2598]: connman_inet_ifname: SIOCGIFNAME(index
4): No such device
00:21:45 roska flimflamd[2598]: src/rtnl.c:rtnl_message() buf
0xbfefda3c len 1004
00:21:45 roska flimflamd[2598]: src/rtnl.c:rtnl_message()
NEWLINK len 1004 type 16 flags 0x0000 seq 0
So the kobject is visible in udev before the device is ready.
(ignore the 10 s delay, I added that to reproduce the issue easily)
The issue is reported here:
https://bugzilla.kernel.org/show_bug.cgi?id=15606
The fix is to call netdev_register_kobject() after the device is added
to the list.
Signed-off-by: Kalle Valo <kalle.valo-DlyHzToyqoxBDgjK7y7TUQ@public.gmane.org>
---
net/core/dev.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 956d3b0..f2afbe6 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5425,11 +5425,6 @@ int register_netdevice(struct net_device *dev)
if (ret)
goto err_uninit;
- ret = netdev_register_kobject(dev);
- if (ret)
- goto err_uninit;
- dev->reg_state = NETREG_REGISTERED;
^ permalink raw reply related
* Re: linux-next: Tree for April 29 (bpf_jit)
From: David Miller @ 2011-04-29 17:21 UTC (permalink / raw)
To: eric.dumazet; +Cc: randy.dunlap, sfr, netdev, linux-next, linux-kernel
In-Reply-To: <1304097558.2686.6.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 29 Apr 2011 19:19:18 +0200
> [PATCH net-next-2.6] bpf: depends on MODULES
>
> module_alloc() and module_free() are available only if CONFIG_MODULES=y
>
> Reported-by: Randy Dunlap <randy.dunlap@oracle.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks.
Perhaps we can solve these things by seperating out the dependency,
via "CONFIG_MODULE_ALLOC" and making things like KPROBES and
BPF 'select' it.
^ permalink raw reply
* Re: A race in register_netdevice()
From: Kalle Valo @ 2011-04-29 17:20 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, linux-wireless
In-Reply-To: <20110428165237.0c1eddbc@nehalam>
Stephen Hemminger <shemminger@vyatta.com> writes:
> On Fri, 29 Apr 2011 01:36:37 +0300
>
>> there seems to be a race in register_netdevice(), which is reported here:
>>
>> https://bugzilla.kernel.org/show_bug.cgi?id=15606
>>
>> This is visible at least with flimflam and ath6kl. Basically what
>> happens is this:
>>
>> Apr 29 00:21:35 roska flimflamd[2598]: src/udev.c:add_net_device()
>> Apr 29 00:21:35 roska flimflamd[2598]: connman_inet_ifname: SIOCGIFNAME(index
>> 4): No such device
>> Apr 29 00:21:45 roska flimflamd[2598]: src/rtnl.c:rtnl_message() buf
>> 0xbfefda3c len 1004
>> Apr 29 00:21:45 roska flimflamd[2598]: src/rtnl.c:rtnl_message()
>> NEWLINK len 1004 type 16 flags 0x0000 seq 0
[...]
>> I have confirmed that both of these patches fix the issue. Now I'm
>> wondering which one is the best way forward. Or is there a better way
>> to fix this?
>>
>
> I see no problem with moving this.
> SIOCGIFNAME should not need to hold rtnl.
Ok, thanks for comments. I'll send a proper patch.
--
Kalle Valo
^ permalink raw reply
* Re: linux-next: Tree for April 29 (bpf_jit)
From: Eric Dumazet @ 2011-04-29 17:19 UTC (permalink / raw)
To: Randy Dunlap, David Miller; +Cc: Stephen Rothwell, netdev, linux-next, LKML
In-Reply-To: <20110429092632.26ff1e53.randy.dunlap@oracle.com>
Le vendredi 29 avril 2011 à 09:26 -0700, Randy Dunlap a écrit :
> On Fri, 29 Apr 2011 13:19:40 +1000 Stephen Rothwell wrote:
>
> > Hi all,
> >
> > Changes since 20110428:
>
>
> when CONFIG_MODULES is not enabled:
>
> bpf_jit_comp.c:(.text+0x43cc2): undefined reference to `module_free'
> (.text+0x4521a): undefined reference to `module_alloc'
> (.text+0x453af): undefined reference to `module_free'
>
>
Oh well, I guess we can add one 'depends on MODULES' like we do for
KPROBES (it also uses module_alloc())
Not sure many people build a !CONFIG_MODULES kernel these days...
Thanks Randy !
[PATCH net-next-2.6] bpf: depends on MODULES
module_alloc() and module_free() are available only if CONFIG_MODULES=y
Reported-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/Kconfig | 1 +
1 files changed, 1 insertion(+)
diff --git a/net/Kconfig b/net/Kconfig
index 745fb02..878151c 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -238,6 +238,7 @@ config HAVE_BPF_JIT
config BPF_JIT
bool "enable BPF Just In Time compiler"
depends on HAVE_BPF_JIT
+ depends on MODULES
---help---
Berkeley Packet Filter filtering capabilities are normally handled
by an interpreter. This option allows kernel to generate a native
^ permalink raw reply related
* Re: Is 802.3ad mode in bonding useful ?
From: Jay Vosburgh @ 2011-04-29 17:01 UTC (permalink / raw)
To: Neil Horman; +Cc: WeipingPan, netdev
In-Reply-To: <20110429104342.GA22387@hmsreliant.think-freely.org>
Neil Horman <nhorman@tuxdriver.com> wrote:
>On Fri, Apr 29, 2011 at 11:17:48AM +0800, WeipingPan wrote:
>> On 04/28/2011 08:21 PM, Neil Horman wrote:
>> >On Thu, Apr 28, 2011 at 03:33:50PM +0800, WeipingPan wrote:
>> >>Hi, all,
>> >>
>> >>802.3ad mode in bonding implements 802.3ad standard.
>> >>
>> >>I am just wondering 802.3ad mode is useful,
>> >>since bonding has many modes like balance-rr, active-backup, etc.
>> >>
>> >Yes, of course its usefull. For switches which support 802.3ad, this mode
>> >allows for both peers to understand that the links in the bond are acting as an
>> >aggregate, which makes it easier to prevent things like inadvertently looped
>> >back frames, for which the other modes have to have all sorts of hacks to
>> >prevent.
>> What is looped back frames here ?
>In this case they are frames that get received by the bond, which the bond
>itself sent. In modes where more than one slave is active, and in which the
>switch has no additional knoweldge of the aggregate (e.g. round robin mode), the
>bond can send a frame on one slave, which the switch may broadcast to all ports,
>causing the frame just sent by the bond to then get received on another slave.
Actually, the round-robin (balance-rr) and balance-xor modes
were originally meant to interoperate with a switch configured for
traditional Etherchannel (old versions of Sun Trunking, etc) the common
term in use now seems to be "static link aggregation" to distinguish it
from 802.3ad dynamic link aggregation. When the switch is set up that
way, there are no loopback problems, because the switch knows that all
of the ports are really one big aggregate, and it won't send broadcast
or multicast packets to more than one port of the aggregation, and knows
that a bcast/mcast originating from one of those ports should not loop
back to another port of the aggregation.
What Neil is talking about is running -rr or -xor against,
basically, a hub or unmanaged switch, in which the switch (a) doesn't
have any link aggregation capabilities, and (b) won't complain when it
sees the same MAC address coming in from multiple ports more or less
simultaneously. Managed switches (that have link aggregation
capabilities) will generally complain about "flapping" if they see the
same source MAC address arrive on multiple switch ports in a short
period of time.
The special hacks now in bond_handle_frame aren't really about
preventing loopbacks, but rather to suppress duplicates, particularly
for the short periods of time that a switch is flooding traffic to all
ports because its mac table is not up to date. This is an issue in,
e.g., active-backup mode, in which the switch has no special
configuration. This code has moved around a lot lately, so older
kernels will have a substantially different layout, although the logic
is still pretty much the same.
I don't recall that there's anything specifically to suppress
loopbacks for -rr or -xor mode, although there is transmit logic to keep
things like IGMP messages on the same slave all the time to keep the
switches happier.
>> I didn't see any special code to handle looped back frames in other
>> modes in bonding,
>> can you take an example ?
>>
>See bond_handle_frame.
The actual testing logic is in bond_should_deliver_exact_match.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: linux-next: Tree for April 29 (bpf_jit)
From: Randy Dunlap @ 2011-04-29 16:26 UTC (permalink / raw)
To: Stephen Rothwell, netdev; +Cc: linux-next, LKML
In-Reply-To: <20110429131940.4f4c938f.sfr@canb.auug.org.au>
On Fri, 29 Apr 2011 13:19:40 +1000 Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20110428:
when CONFIG_MODULES is not enabled:
bpf_jit_comp.c:(.text+0x43cc2): undefined reference to `module_free'
(.text+0x4521a): undefined reference to `module_alloc'
(.text+0x453af): undefined reference to `module_free'
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH] bridge: Module use count must be updated as bridges are created/destroyed
From: Jon Masters @ 2011-04-29 16:05 UTC (permalink / raw)
To: Michal Marek
Cc: Jan Beulich, David Miller, shemminger, bridge, jeffm, netdev,
Jon Masters
In-Reply-To: <4DBA9C23.2000408@suse.cz>
On Fri, 2011-04-29 at 13:08 +0200, Michal Marek wrote:
> On 29.4.2011 11:09, Jan Beulich wrote:
> >>>> On 29.04.11 at 10:44, David Miller<davem@davemloft.net> wrote:
> >> Nothing on the system should be hitting modules with unload requests
> >> unless the user explicitly asked for that specific module to be
> >> unloaded. At least not by default.
> >>
> >> So the me the problem is perhaps that "modprobe -r" does this auto
> >> dependency unloading thing by default.
> >>
> >> When we first fixed network device drivers so that they now properly
> >> always run with no module refcount at all, people complained because
> >> there were some distributions that ran some daemon that periodically
> >> looked for "unreferenced" modules and "helped" the user by
> >> automatically unloaded them.
> >>
> >> We killed that foolish daemon, and we can fix "modprobe -r" too.
> >
> > Michal - aren't you the modutils maintainer?
>
> That would be Jon (CC added).
Thanks. So the specific feature you mention was added precisely because
some folks wanted to clean up ununsed modules by removing all of their
dependencies. Since I've not been on this thread until now, can you let
me know what precisely you need, and why? We can make the unloading of
unused modules configurable, but it sounds like you're saying even that
isn't good enough. What actually happens, what's the bug experience?
I realize there isn't a general fondness of module removing, and I for
one don't really mind having a few extra modules loaded in my kernel.
Jon.
^ permalink raw reply
* Re: [PATCH] bridge: Module use count must be updated as bridges are created/destroyed
From: Jon Masters @ 2011-04-29 16:20 UTC (permalink / raw)
To: Jan Beulich
Cc: David Miller, Jon Masters, shemminger, bridge, jeffm,
Michal Marek, netdev
In-Reply-To: <4DBAFE45020000780003EEE6@vpn.id2.novell.com>
On Fri, 2011-04-29 at 17:07 +0100, Jan Beulich wrote:
> >>> On 29.04.11 at 18:05, Jon Masters <jonathan@jonmasters.org> wrote:
> > On Fri, 2011-04-29 at 13:08 +0200, Michal Marek wrote:
> >> On 29.4.2011 11:09, Jan Beulich wrote:
> >> >>>> On 29.04.11 at 10:44, David Miller<davem@davemloft.net> wrote:
> >
> >> >> Nothing on the system should be hitting modules with unload requests
> >> >> unless the user explicitly asked for that specific module to be
> >> >> unloaded. At least not by default.
> >> >>
> >> >> So the me the problem is perhaps that "modprobe -r" does this auto
> >> >> dependency unloading thing by default.
> >> >>
> >> >> When we first fixed network device drivers so that they now properly
> >> >> always run with no module refcount at all, people complained because
> >> >> there were some distributions that ran some daemon that periodically
> >> >> looked for "unreferenced" modules and "helped" the user by
> >> >> automatically unloaded them.
> >> >>
> >> >> We killed that foolish daemon, and we can fix "modprobe -r" too.
> >> >
> >> > Michal - aren't you the modutils maintainer?
> >>
> >> That would be Jon (CC added).
> >
> > Thanks. So the specific feature you mention was added precisely because
> > some folks wanted to clean up ununsed modules by removing all of their
> > dependencies. Since I've not been on this thread until now, can you let
> > me know what precisely you need, and why? We can make the unloading of
> > unused modules configurable, but it sounds like you're saying even that
> > isn't good enough. What actually happens, what's the bug experience?
>
> The problem observed was that unloading (via modprobe -r)
> ebtable_broute.ko, bridge.ko was also unloaded, causing all
> bridged networking to stop functioning on a machine.
Ah, right...ouch. That would be a "little" problem. Short of having an
exclusion list and all that nonsense, probably best to start with either
removing the unload logic or making it globally configurable. Thanks.
Jon.
^ permalink raw reply
* Re: [PATCH] bridge: Module use count must be updated as bridges are created/destroyed
From: Jan Beulich @ 2011-04-29 16:07 UTC (permalink / raw)
To: Jon Masters
Cc: David Miller, Jon Masters, shemminger, bridge, jeffm,
Michal Marek, netdev
In-Reply-To: <1304093116.11627.386.camel@constitution.bos.jonmasters.org>
>>> On 29.04.11 at 18:05, Jon Masters <jonathan@jonmasters.org> wrote:
> On Fri, 2011-04-29 at 13:08 +0200, Michal Marek wrote:
>> On 29.4.2011 11:09, Jan Beulich wrote:
>> >>>> On 29.04.11 at 10:44, David Miller<davem@davemloft.net> wrote:
>
>> >> Nothing on the system should be hitting modules with unload requests
>> >> unless the user explicitly asked for that specific module to be
>> >> unloaded. At least not by default.
>> >>
>> >> So the me the problem is perhaps that "modprobe -r" does this auto
>> >> dependency unloading thing by default.
>> >>
>> >> When we first fixed network device drivers so that they now properly
>> >> always run with no module refcount at all, people complained because
>> >> there were some distributions that ran some daemon that periodically
>> >> looked for "unreferenced" modules and "helped" the user by
>> >> automatically unloaded them.
>> >>
>> >> We killed that foolish daemon, and we can fix "modprobe -r" too.
>> >
>> > Michal - aren't you the modutils maintainer?
>>
>> That would be Jon (CC added).
>
> Thanks. So the specific feature you mention was added precisely because
> some folks wanted to clean up ununsed modules by removing all of their
> dependencies. Since I've not been on this thread until now, can you let
> me know what precisely you need, and why? We can make the unloading of
> unused modules configurable, but it sounds like you're saying even that
> isn't good enough. What actually happens, what's the bug experience?
The problem observed was that unloading (via modprobe -r)
ebtable_broute.ko, bridge.ko was also unloaded, causing all
bridged networking to stop functioning on a machine.
Jan
^ permalink raw reply
* Re: same application has different performance with kernel 2.6.32/34/36
From: Stephen Hemminger @ 2011-04-29 15:48 UTC (permalink / raw)
To: zhou rui; +Cc: netdev, jon.zhou
In-Reply-To: <BANLkTinF8Mfs+pqfGV0bLqm_3VyKCMn0LA@mail.gmail.com>
On Fri, 29 Apr 2011 22:46:04 +0800
zhou rui <zhourui.cn@gmail.com> wrote:
> hi
> my test application add a packet hook via dev_add_pack(&prot_hook);
> then copy the packet to a shared memory between userspace and kernel
>
> tests wereperformed at same machine(DL380 G7, 12cores, intel X520 10G
> nic),same traffic,same nic driver(ixgbe 3.3.9)
>
> kernel 2.6.32.12 (SUSE SLES11,SP1)
> APPlication cpu usage: 5-6%
>
>
> kernel updated to 2.6.34.7
> APPlication cpu usage: 19-25%
>
> kernel 2.6.36.4 (enable/disable RPS)
> APPlication cpu usage 35-40%
>
>
> before I installing profile tool to find the root cause, any idea about it?
> 'top' result is not accurate in older kernel? or any kernel
> module/feature impact this?
The report is appreciated, but since your application is not part of the main
kernel, developers are going to be unable to provide much direct help.
If it is closed source, go away we won't help with closed kernel components.
If it is open source, post a link where people can download it.
This is the kind of problem that requires effort and running multiple
times and using kernel bisection can show which change had the most impact.
It could be driver, scheduling or the change to packet steering.
^ permalink raw reply
* Re: [PATCH] bridge: Module use count must be updated as bridges are created/destroyed
From: Stephen Hemminger @ 2011-04-29 15:34 UTC (permalink / raw)
To: David Miller; +Cc: JBeulich, bridge, jeffm, netdev
In-Reply-To: <20110429.002530.112581952.davem@davemloft.net>
On Fri, 29 Apr 2011 00:25:30 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: "Jan Beulich" <JBeulich@novell.com>
> Date: Fri, 29 Apr 2011 08:21:14 +0100
>
> > Otherwise 'modprobe -r' on a module having a dependency on bridge will
> > implicitly unload bridge, bringing down all connectivity that was using
> > bridges.
> >
> > Signed-off-by: Jan Beulich <jbeulich@novell.com>
> > Cc: Jeff Mahoney <jeffm@suse.com>
>
> All network device drivers behave exactly the same way, when you rmmod
> the thing we unconfigure all the routes, addresses, etc. going through
> that device and let you unload it.
>
> And this behavior is very much intentional.
>
> Don't add an exception here.
Agreed.
^ permalink raw reply
* Re: Is 802.3ad mode in bonding useful ?
From: Rick Jones @ 2011-04-29 15:21 UTC (permalink / raw)
To: John Lumby; +Cc: Neil Horman, WeipingPan, netdev
In-Reply-To: <4DBAC552.507@hotmail.com>
> >> What is looped back frames here ?
> > In this case they are frames that get received by the bond, which the bond
> > itself sent. In modes where more than one slave is active, and in which the
> > switch has no additional knoweldge of the aggregate (e.g. round robin mode), the
> > bond can send a frame on one slave, which the switch may broadcast to all ports,
>
>
> Isn't this (broadcasting or repeating on all ports other than incoming)
> more associated with simple hubs rather than switches? I would think
> any switch with layer 2 capability does not do that (does it?)
Perhaps when a frame is sent via the bond to a destination MAC not yet
learned by the switch?
Until a switch sees a MAC as a src, it does not know to which port the
frame(s) should be forwarded, so it must send the frame out all ports
but the ingress port.
rick jones
^ permalink raw reply
* same application has different performance with kernel 2.6.32/34/36
From: zhou rui @ 2011-04-29 14:46 UTC (permalink / raw)
To: netdev; +Cc: jon.zhou
hi
my test application add a packet hook via dev_add_pack(&prot_hook);
then copy the packet to a shared memory between userspace and kernel
tests wereperformed at same machine(DL380 G7, 12cores, intel X520 10G
nic),same traffic,same nic driver(ixgbe 3.3.9)
kernel 2.6.32.12 (SUSE SLES11,SP1)
APPlication cpu usage: 5-6%
kernel updated to 2.6.34.7
APPlication cpu usage: 19-25%
kernel 2.6.36.4 (enable/disable RPS)
APPlication cpu usage 35-40%
before I installing profile tool to find the root cause, any idea about it?
'top' result is not accurate in older kernel? or any kernel
module/feature impact this?
^ permalink raw reply
* Re: oops during unregister_netdevice interface enslaved to bond - regression
From: Einar EL Lueck @ 2011-04-29 14:45 UTC (permalink / raw)
To: opurdila, netdev, linux-s390, davem; +Cc: Frank Blaschka
Hi Octavian,
On 04/15/2011 10:53 AM, Frank Blaschka wrote:
> Hi Octavian,
>
> your commit 443457242beb6716b43db4d62fe148eab5515505 introduced this
regression.
> I have reviewed the net device unregister code but did not understand it
very well.
> I have seen the problem only in combination with bonding. Can you give me
some help
> how to go on with this problem. I can reproduced it very easy on a single
CPU
> machine.
>
In this case rollback_registered_many iterates over the list of devs that
initially has just one device in it. In a loop it calls
call_netdevice_notifiers(NETDEV_UNREGISTER, dev) which triggers the bonding
driver to call dev_close_many for the same device. That call to
dev_close_many leads to the addition of the same device to the list over
which rollback_registered_many is iterating. Consequently,
netdev_unregister_kobject(dev) is called twice for the same device. Frank
captured the result in his mail.
Do you agree with my debugging results?
Regards,
Einar.
^ permalink raw reply
* Re: Is 802.3ad mode in bonding useful ?
From: John Lumby @ 2011-04-29 14:04 UTC (permalink / raw)
To: Neil Horman; +Cc: WeipingPan, netdev
In-Reply-To: <20110429104342.GA22387@hmsreliant.think-freely.org>
On 04/29/11 06:43, Neil Horman wrote:
> On Fri, Apr 29, 2011 at 11:17:48AM +0800, WeipingPan wrote:
>> On 04/28/2011 08:21 PM, Neil Horman wrote:
>>> On Thu, Apr 28, 2011 at 03:33:50PM +0800, WeipingPan wrote:
>>>> Hi, all,
>>>>
>>>> 802.3ad mode in bonding implements 802.3ad standard.
>>>>
>>>> I am just wondering 802.3ad mode is useful,
>>>> since bonding has many modes like balance-rr, active-backup, etc.
>>>>
>>> Yes, of course its usefull. For switches which support 802.3ad, this mode
>>> allows for both peers to understand that the links in the bond are acting as an
>>> aggregate, which makes it easier to prevent things like inadvertently looped
>>> back frames, for which the other modes have to have all sorts of hacks to
>>> prevent.
I believe another use for 802.3ad is to monitor the aggregation
"actively" (by sending special LACP packets) and to detect any kind of
failure of the other end of one of the slaves more rapidly (than if
relying on something like carrier detect). This may improve
availability, although that depends on the specific network topology
and capabilities in the switch(es). There is information on this in
Documentation/networking/bonding.txt.
>> What is looped back frames here ?
> In this case they are frames that get received by the bond, which the bond
> itself sent. In modes where more than one slave is active, and in which the
> switch has no additional knoweldge of the aggregate (e.g. round robin mode), the
> bond can send a frame on one slave, which the switch may broadcast to all ports,
Isn't this (broadcasting or repeating on all ports other than incoming)
more associated with simple hubs rather than switches? I would think
any switch with layer 2 capability does not do that (does it?)
> causing the frame just sent by the bond to then get received on another slave.
>
>
^ permalink raw reply
* Re: Is 802.3ad mode in bonding useful ?
From: WeipingPan @ 2011-04-29 13:59 UTC (permalink / raw)
To: Neil Horman; +Cc: netdev
In-Reply-To: <20110429104342.GA22387@hmsreliant.think-freely.org>
On 04/29/2011 06:43 PM, Neil Horman wrote:
> On Fri, Apr 29, 2011 at 11:17:48AM +0800, WeipingPan wrote:
>> On 04/28/2011 08:21 PM, Neil Horman wrote:
>>> On Thu, Apr 28, 2011 at 03:33:50PM +0800, WeipingPan wrote:
>>>> Hi, all,
>>>>
>>>> 802.3ad mode in bonding implements 802.3ad standard.
>>>>
>>>> I am just wondering 802.3ad mode is useful,
>>>> since bonding has many modes like balance-rr, active-backup, etc.
>>>>
>>> Yes, of course its usefull. For switches which support 802.3ad, this mode
>>> allows for both peers to understand that the links in the bond are acting as an
>>> aggregate, which makes it easier to prevent things like inadvertently looped
>>> back frames, for which the other modes have to have all sorts of hacks to
>>> prevent.
>> What is looped back frames here ?
> In this case they are frames that get received by the bond, which the bond
> itself sent. In modes where more than one slave is active, and in which the
> switch has no additional knoweldge of the aggregate (e.g. round robin mode), the
> bond can send a frame on one slave, which the switch may broadcast to all ports,
> causing the frame just sent by the bond to then get received on another slave.
>
>> I didn't see any special code to handle looped back frames in other
>> modes in bonding,
>> can you take an example ?
>>
> See bond_handle_frame.
>
> Neil
>
Oh, I got it.
Thanks for your clear explanation !
Weiping Pan
^ permalink raw reply
* Re: [PATCH net-next-2.6] veth: remove unneeded ifname code from veth_newlink()
From: Jiri Pirko @ 2011-04-29 13:51 UTC (permalink / raw)
To: David Miller; +Cc: mirqus, netdev, xemul
In-Reply-To: <20110428.132724.48500963.davem@davemloft.net>
Thu, Apr 28, 2011 at 10:27:24PM CEST, davem@davemloft.net wrote:
>From: Michał Mirosław <mirqus@gmail.com>
>Date: Fri, 22 Apr 2011 11:49:40 +0200
>
>> W dniu 22 kwietnia 2011 11:43 użytkownik Michał Mirosław
>> <mirqus@gmail.com> napisał:
>>> 2011/1/24 Jiri Pirko <jpirko@redhat.com>:
>>>> The code is not needed because tb[IFLA_IFNAME] is already
>>>> processed in rtnl_newlink(). Remove this redundancy.
>>> Hi. This patch broke creation of veth devices. Reverting it fixes the issue.
>>>
>>> Symptoms:
>>>
>>> icybox:~# ip link add type veth
>>> RTNETLINK answers: File exists
>>> icybox:~# ip link add type veth peer veth1
>>> icybox:~# ip addr
>>> [...]
>>> 56: D: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
>>> link/ether e6:57:58:52:03:50 brd ff:ff:ff:ff:ff:ff
>>> 57: veth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
>>> link/ether c2:c2:a2:d5:d5:3a brd ff:ff:ff:ff:ff:ff
>>
>> Hmm. I was too quick. Reverting it fixes only first problem - "ip link
>> add type veth" adds new veth pair now, but "ip link add type veth peer
>> veth1" gives the same result as above.
>
>Jiri please look into this regression.
Working on this. Will post patch soon.
Jirka
^ permalink raw reply
* [PATCH] usbnet: Transfer of maintainership
From: Oliver Neukum @ 2011-04-29 12:19 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q, netdev-u79uwXL29TY76Z2rM5mHXA,
USB list
>From 8786db859938a1be111b5b3a86161d38da5ac8db Mon Sep 17 00:00:00 2001
From: Oliver Neukum <oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org>
Date: Fri, 29 Apr 2011 14:15:53 +0200
Subject: [PATCH] usbnet: Transfer of maintainership
Somebody has to do it, however unfortunate be the cause.
Signed-off-by: Oliver Neukum <oneukum-l3A5Bk7waGM@public.gmane.org>
---
MAINTAINERS | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 2199ba1..16a5c5f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6556,7 +6556,7 @@ S: Maintained
F: drivers/usb/host/uhci*
USB "USBNET" DRIVER FRAMEWORK
-M: David Brownell <dbrownell-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
+M: Oliver Neukum <oneukum-l3A5Bk7waGM@public.gmane.org>
L: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
W: http://www.linux-usb.org/usbnet
S: Maintained
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] bridge: Module use count must be updated as bridges are created/destroyed
From: Michal Marek @ 2011-04-29 11:08 UTC (permalink / raw)
To: Jan Beulich; +Cc: David Miller, shemminger, bridge, jeffm, netdev, Jon Masters
In-Reply-To: <4DBA9C71020000780003EDBE@vpn.id2.novell.com>
On 29.4.2011 11:09, Jan Beulich wrote:
>>>> On 29.04.11 at 10:44, David Miller<davem@davemloft.net> wrote:
>> From: "Jan Beulich"<JBeulich@novell.com>
>> Date: Fri, 29 Apr 2011 09:31:27 +0100
>>
>>>>>> On 29.04.11 at 10:10, David Miller<davem@davemloft.net> wrote:
>>>> From: "Jan Beulich"<JBeulich@novell.com>
>>>> Date: Fri, 29 Apr 2011 08:41:10 +0100
>>>>
>>>>> You talk of rmmod on the very module, but the issue is about
>>>>> modprobe -r on a dependent module. I cannot believe you consider
>>>>> it correct that *implicit* unloading of bridge.ko should happen when
>>>>> bridges are configured.
>>>>
>>>> Which module in particular depends upon bridge and causes the
>>>> problem?
>>>
>>> The problem was observed (a long time ago) with ebtable_broute,
>>> and I cannot see how this would have changed meanwhile.
>>
>> Well your change makes it so that someone who actually _wants_ to
>> unload the bridge module, regardless of configuration, cannot do so.
>>
>> I think that's a worse problem than this ebtables thing.
>>
>> Nothing on the system should be hitting modules with unload requests
>> unless the user explicitly asked for that specific module to be
>> unloaded. At least not by default.
>>
>> So the me the problem is perhaps that "modprobe -r" does this auto
>> dependency unloading thing by default.
>>
>> When we first fixed network device drivers so that they now properly
>> always run with no module refcount at all, people complained because
>> there were some distributions that ran some daemon that periodically
>> looked for "unreferenced" modules and "helped" the user by
>> automatically unloaded them.
>>
>> We killed that foolish daemon, and we can fix "modprobe -r" too.
>
> Michal - aren't you the modutils maintainer?
That would be Jon (CC added).
> What are your thoughts
> here? (The original report we got is
> https://bugzilla.novell.com/show_bug.cgi?id=267651.)
I think that defaulting to not removing dependencies would be a good
idea. But do not expect that it will help with those artificial tests,
they will just proceed a few steps further until they hit the module
with broken unloading ;-).
Michal
>
>> Does "rmmod" have this behavior too? If not, and it does the right
>> thing by only unloaded what the user asked for, then people should
>> use that.
>
> No, it doesn't. Other than modprobe, rmmod deals only with the
> module specified.
>
>> I really don't in any way want to block people from being able to
>> cleanly unload the bridge module, regardless of configuration, if
>> that's what they want so your patch as written is not going to be
>> considered for inclusion.
>
> I understood that meanwhile, yet fail to see an alternative solution
> (imo this auto-unloading is quite desirable in other cases).
>
> Jan
>
^ permalink raw reply
* Re: Is 802.3ad mode in bonding useful ?
From: Neil Horman @ 2011-04-29 10:43 UTC (permalink / raw)
To: WeipingPan; +Cc: netdev
In-Reply-To: <4DBA2DDC.80502@gmail.com>
On Fri, Apr 29, 2011 at 11:17:48AM +0800, WeipingPan wrote:
> On 04/28/2011 08:21 PM, Neil Horman wrote:
> >On Thu, Apr 28, 2011 at 03:33:50PM +0800, WeipingPan wrote:
> >>Hi, all,
> >>
> >>802.3ad mode in bonding implements 802.3ad standard.
> >>
> >>I am just wondering 802.3ad mode is useful,
> >>since bonding has many modes like balance-rr, active-backup, etc.
> >>
> >Yes, of course its usefull. For switches which support 802.3ad, this mode
> >allows for both peers to understand that the links in the bond are acting as an
> >aggregate, which makes it easier to prevent things like inadvertently looped
> >back frames, for which the other modes have to have all sorts of hacks to
> >prevent.
> What is looped back frames here ?
In this case they are frames that get received by the bond, which the bond
itself sent. In modes where more than one slave is active, and in which the
switch has no additional knoweldge of the aggregate (e.g. round robin mode), the
bond can send a frame on one slave, which the switch may broadcast to all ports,
causing the frame just sent by the bond to then get received on another slave.
> I didn't see any special code to handle looped back frames in other
> modes in bonding,
> can you take an example ?
>
See bond_handle_frame.
Neil
> thanks
> Weiping Pan
>
> >Neil
> >
>
>
^ permalink raw reply
* Re: [PATCH] s390, net: convert into new cpumask api
From: Ursula Braun @ 2011-04-29 10:01 UTC (permalink / raw)
To: KOSAKI Motohiro
Cc: LKML, Martin Schwidefsky, Heiko Carstens, Ursula Braun,
David S. Miller, linux390, linux-s390, netdev
In-Reply-To: <20110429000104.3D5D.A69D9226@jp.fujitsu.com>
On Thu, 2011-04-28 at 23:59 +0900, KOSAKI Motohiro wrote:
> Adapt new api.
>
> Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
> Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
> Cc: Ursula Braun <ursula.braun@de.ibm.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: linux390@de.ibm.com
> Cc: linux-s390@vger.kernel.org
> Cc: netdev@vger.kernel.org
> ---
> net/iucv/iucv.c | 70 +++++++++++++++++++++++++++---------------------------
> 1 files changed, 35 insertions(+), 35 deletions(-)
>
> diff --git a/net/iucv/iucv.c b/net/iucv/iucv.c
> index 8f156bd..79f2caf 100644
> --- a/net/iucv/iucv.c
> +++ b/net/iucv/iucv.c
> @@ -128,8 +128,8 @@ struct iucv_irq_list {
> };
>
> static struct iucv_irq_data *iucv_irq_data[NR_CPUS];
> -static cpumask_t iucv_buffer_cpumask = CPU_MASK_NONE;
> -static cpumask_t iucv_irq_cpumask = CPU_MASK_NONE;
> +static cpumask_t iucv_buffer_cpumask = { CPU_BITS_NONE };
> +static cpumask_t iucv_irq_cpumask = { CPU_BITS_NONE };
...
Applied and merged to our tree.
Thanks!
^ permalink raw reply
* RE: [v2 PATCH 0/6] IPVS: init and cleanup.
From: Hans Schillström @ 2011-04-29 9:48 UTC (permalink / raw)
To: Simon Horman, Hans Schillstrom
Cc: ja@ssi.bg, ebiederm@xmission.com, lvs-devel@vger.kernel.org,
netdev@vger.kernel.org, netfilter-devel@vger.kernel.org
In-Reply-To: <20110429064225.GA23958@verge.net.au>
>Subject: Re: [v2 PATCH 0/6] IPVS: init and cleanup.
>
>On Fri, Apr 29, 2011 at 08:25:28AM +0200, Hans Schillstrom wrote:
> This patch series handles exit from a network name space.
>
>Hi Hans,
>
>thanks for your work on this.
>I've looked over the patches and nothing catches my eye -
>thanks for fixing up the things that I commented on previously.
>
>I think that patches 1 and 2 should be targeted at 2.6.39,
>while the remainder look like 2.6.40 material. Does that
>sound reasonable to you?
I do prefer to keep them together,
but if you want it in that way it's OK for me.
We are doing a lot of tests right now with this patch set.
If we found any issues I'll let you know.
Regards
Hans
^ permalink raw reply
* Re: [PATCH] bridge: Module use count must be updated as bridges are created/destroyed
From: Jan Beulich @ 2011-04-29 9:09 UTC (permalink / raw)
To: David Miller, Michal Marek; +Cc: shemminger, bridge, jeffm, netdev
In-Reply-To: <20110429.014445.39196872.davem@davemloft.net>
>>> On 29.04.11 at 10:44, David Miller <davem@davemloft.net> wrote:
> From: "Jan Beulich" <JBeulich@novell.com>
> Date: Fri, 29 Apr 2011 09:31:27 +0100
>
>>>>> On 29.04.11 at 10:10, David Miller <davem@davemloft.net> wrote:
>>> From: "Jan Beulich" <JBeulich@novell.com>
>>> Date: Fri, 29 Apr 2011 08:41:10 +0100
>>>
>>>> You talk of rmmod on the very module, but the issue is about
>>>> modprobe -r on a dependent module. I cannot believe you consider
>>>> it correct that *implicit* unloading of bridge.ko should happen when
>>>> bridges are configured.
>>>
>>> Which module in particular depends upon bridge and causes the
>>> problem?
>>
>> The problem was observed (a long time ago) with ebtable_broute,
>> and I cannot see how this would have changed meanwhile.
>
> Well your change makes it so that someone who actually _wants_ to
> unload the bridge module, regardless of configuration, cannot do so.
>
> I think that's a worse problem than this ebtables thing.
>
> Nothing on the system should be hitting modules with unload requests
> unless the user explicitly asked for that specific module to be
> unloaded. At least not by default.
>
> So the me the problem is perhaps that "modprobe -r" does this auto
> dependency unloading thing by default.
>
> When we first fixed network device drivers so that they now properly
> always run with no module refcount at all, people complained because
> there were some distributions that ran some daemon that periodically
> looked for "unreferenced" modules and "helped" the user by
> automatically unloaded them.
>
> We killed that foolish daemon, and we can fix "modprobe -r" too.
Michal - aren't you the modutils maintainer? What are your thoughts
here? (The original report we got is
https://bugzilla.novell.com/show_bug.cgi?id=267651.)
> Does "rmmod" have this behavior too? If not, and it does the right
> thing by only unloaded what the user asked for, then people should
> use that.
No, it doesn't. Other than modprobe, rmmod deals only with the
module specified.
> I really don't in any way want to block people from being able to
> cleanly unload the bridge module, regardless of configuration, if
> that's what they want so your patch as written is not going to be
> considered for inclusion.
I understood that meanwhile, yet fail to see an alternative solution
(imo this auto-unloading is quite desirable in other cases).
Jan
^ permalink raw reply
* Re: Maximum no of bytes Ethernet can transfer at a time ??
From: Ajit @ 2011-04-29 8:53 UTC (permalink / raw)
To: netdev
In-Reply-To: <20110428110634.GA4165@hmsreliant.think-freely.org>
Neil Horman <nhorman <at> tuxdriver.com> writes:
I forgot to mention one more thing,
In the sender code you need to edit the mac of the target machine.
you will find it at the start of the code.
Also take care of eth0 to eth1 in the receiver code as per the need.
Thank you.
^ 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