* Re: [net-next PATCH v1 1/7] net: add generic PF_BRIDGE:RTM_ FDB hooks
From: Ben Hutchings @ 2012-04-11 16:05 UTC (permalink / raw)
To: John Fastabend
Cc: roprabhu, mst, stephen.hemminger, davem, hadi, jeffrey.t.kirsher,
netdev, gregory.v.rose, krkumar2, sri
In-Reply-To: <4F85991A.5030808@intel.com>
On Wed, 2012-04-11 at 07:45 -0700, John Fastabend wrote:
> On 4/10/2012 8:23 PM, Ben Hutchings wrote:
> > On Mon, 2012-04-09 at 15:00 -0700, John Fastabend wrote:
> > [...]
> >> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> >> index 1f77540..05822e5 100644
> >> --- a/include/linux/netdevice.h
> >> +++ b/include/linux/netdevice.h
> > [...]
> >> @@ -905,6 +906,19 @@ struct netdev_fcoe_hbainfo {
> >> * feature set might be less than what was returned by ndo_fix_features()).
> >> * Must return >0 or -errno if it changed dev->features itself.
> >> *
> >> + * int (*ndo_fdb_add)(struct ndmsg *ndm, struct net_device *dev,
> >> + * unsigned char *addr, u16 flags)
> >> + * Adds an FDB entry to dev for addr. The ndmsg contains flags to indicate
> >> + * if the dev->master FDB should be updated or the devices internal FDB.
> >
> > I don't think the second sentence is helpful, as rtnl_fdb_add() will
> > take care of those flags.
> >
> >> + * int (*ndo_fdb_del)(struct ndmsg *ndm, struct net_device *dev,
> >> + * unsigned char *addr)
> >> + * Deletes the FDB entry from dev coresponding to addr. The ndmsg
> >> + * contains flags to indicate if the dev->master FDB should be
> >> + * updated or the devices internal FDB.
> >
> > Similarly here.
>
> agreed neither seem particularly helpful I'll remove them.
>
> >
> >> + * int (*ndo_fdb_dump)(struct sk_buff *skb, struct netlink_callback *cb,
> >> + * struct net_device *dev, int idx)
> >> + * Used to add FDB entries to dump requests. Implementers should add
> >> + * entries to skb and update idx with the number of entries.
> >> */
> > [...
> >> --- a/net/core/rtnetlink.c
> >> +++ b/net/core/rtnetlink.c
> > [...]
> >> +static int rtnl_fdb_add(struct sk_buff *skb, struct nlmsghdr *nlh, void *arg)
> >> +{
> > [...]
> >> + err = -EOPNOTSUPP;
> >
> > So if NTF_MASTER and NTF_SELF are both set, we can quietly fall back to
> > just setting one FDB? Not sure that's really desirable though
> >
>
> It makes it easier to keep an embedded agent and the sw bridge in
> sync if setting both flags adds the entry to both the SW bridge and
> embedded bridge.
Yes, I agree with that.
[...]
> > Wonder what we should do on error here if we've already successfully
> > called ndo_fdb_add on the master? Should we try to roll back the first
> > addition?
> >
>
> The problem with rolling back is the table is likely already updated and
> traffic may already be being forwarded. So I think in this case the user
> will have to query the device to learn what failed. It seems like the
> simplest way to handle this. I think it is unwanted to have traffic being
> forwarded one way for a short period of time then rolled back.
>
> The other idea I just had is we could clear the NTF_ bit in ndm_flags after
> the successful add, del command. I believe the nlmsg gets sent back to the
> user on error I would need to check on this.
[...]
That sounds like a good way of doing it, assuming there's no
compatibility issue.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH 05/10] net: move destructor_arg to the front of sk_buff.
From: Alexander Duyck @ 2012-04-11 16:05 UTC (permalink / raw)
To: Eric Dumazet
Cc: Ian Campbell, netdev, David Miller, Michael S. Tsirkin, Wei Liu,
xen-devel
In-Reply-To: <1334132428.5300.2685.camel@edumazet-glaptop>
On 04/11/2012 01:20 AM, Eric Dumazet wrote:
> On Tue, 2012-04-10 at 12:15 -0700, Alexander Duyck wrote:
>
>> Actually now that I think about it my concerns go much further than the
>> memset. I'm convinced that this is going to cause a pretty significant
>> performance regression on multiple drivers, especially on non x86_64
>> architecture. What we have right now on most platforms is a
>> skb_shared_info structure in which everything up to and including frag 0
>> is all in one cache line. This gives us pretty good performance for igb
>> and ixgbe since that is our common case when jumbo frames are not
>> enabled is to split the head and place the data in a page.
> I dont understand this split thing for MTU=1500 frames.
>
> Even using half a page per fragment, each skb :
>
> needs 2 allocations for sk_buff and skb->head, plus one page alloc /
> reference.
>
> skb->truesize = ksize(skb->head) + sizeof(*skb) + PAGE_SIZE/2 = 512 +
> 256 + 2048 = 2816 bytes
The number you provide for head is currently only available for 128 byte
skb allocations. Anything larger than that will generate a 1K
allocation. Also after all of these patches the smallest size you can
allocate will be 1K for anything under 504 bytes.
The size advantage is actually more for smaller frames. In the case of
igb the behaviour is to place anything less than 512 bytes into just the
header and to skip using the page. As such we get a much more ideal
allocation for small packets. since the truesize is only 1280 in that case.
In the case of ixgbe the advantage is more of a cache miss advantage.
Ixgbe only receives the data into pages now. I can prefetch the first
two cache lines of the page into memory while allocating the skb to
receive it. As such we essentially cut the number of cache misses in
half versus the old approach which had us generating cache misses on the
sk_buff during allocation, and then generating more cache misses again
once we received the buffer and can fill out the sk_buff fields. A
similar size advantage exists as well, but only for frames 256 bytes or
smaller.
> With non split you have :
>
> 2 allocations for sk_buff and skb->head.
>
> skb->truesize = ksize(skb->head) + sizeof(*skb) = 2048 + 256 = 2304
> bytes
>
> less overhead and less calls to page allocator...
>
> This only can benefit if GRO is on, since aggregation can use fragments
> and a single sk_buff, instead of a frag_list
There is much more than true size involved here. My main argument is
that if we are going to align this modified skb_shared_info so that it
is aligned on nr_frags we should do it on all architectures, not just
x86_64.
Thanks,
Alex
^ permalink raw reply
* Who should find out the initial frequency of IBSS join?
From: Felipe Contreras @ 2012-04-11 15:53 UTC (permalink / raw)
To: netdev
Hi,
I'm a total noob at this, but I'm trying to properly fix an issue I'm
having while joining an ad-hoc network with wpa_supplicant; nl80211:
Join IBSS failed. Specifying any frequency makes it work.
Apparently I'm not the only one that has had this issue, however the
fix I found is in NetworkManager[1], but there's a lot of people that
don't use NetworkManager. I tried to file a bug in wpa_supplicant [2],
but they don't think it's a problem there.
Although I think I might be able to write a fix in wpa_supplicant, I
wonder if it might make sense to do it in the nl80211 driver. Wouldn't
it be possible for the driver to check if there's no frequency, and
just try any that is supported?
Cheers.
[1] https://gitorious.org/lanedo/networkmanager/commit/0b5ab39dbf14b4d3d34c4a37b10fa084d0fb272a/diffs
[2] http://w1.fi/bugz/show_bug.cgi?id=439
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v15 04/13] arch/x86: add syscall_get_arch to syscall.h
From: Will Drewry @ 2012-04-11 15:41 UTC (permalink / raw)
To: H. Peter Anvin
Cc: linux-kernel, linux-arch, linux-doc, kernel-hardening, netdev,
x86, arnd, davem, mingo, oleg, peterz, rdunlap, mcgrathr, tglx,
luto, eparis, serge.hallyn, djm, scarybeasts, indan, pmoore, akpm,
corbet, eric.dumazet, markus, coreyb, keescook
In-Reply-To: <4F84F895.4080101@zytor.com>
On Tue, Apr 10, 2012 at 10:20 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 04/10/2012 08:13 PM, Will Drewry wrote:
>> On Sun, Mar 25, 2012 at 2:34 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>>> On 03/14/2012 08:11 PM, Will Drewry wrote:
>>>>
>>>> +static inline int syscall_get_arch(struct task_struct *task,
>>>> + struct pt_regs *regs)
>>>> +{
>>>> +#ifdef CONFIG_IA32_EMULATION
>>>> + /*
>>>> + * TS_COMPAT is set for 32-bit syscall entries and then
>>>> + * remains set until we return to user mode.
>>>> + *
>>>> + * TIF_IA32 tasks should always have TS_COMPAT set at
>>>> + * system call time.
>>>> + */
>>>> + if (task_thread_info(task)->status & TS_COMPAT)
>>>> + return AUDIT_ARCH_I386;
>>>> +#endif
>>>> + return AUDIT_ARCH_X86_64;
>>>> +}
>>>> #endif /* CONFIG_X86_32 */
>>>>
>>>> #endif /* _ASM_X86_SYSCALL_H */
>>>
>>> Just one FYI on this: after the x32 changes are upstream this can be
>>> implemented in terms of is_ia32_task().
>>
>> Now that I've seen is_ia32_task(), it appears to be exactly the same as above:
>> (1) If we're x86_32, it's ia32
>> (2) If we're x86_64, ia32 == !!(status & TS_COMPAT)
>> (3) Otherwise, it's x86_64, including x32
>>
>> Am I missing something? Should is_ia32_task(void) take a task_struct?
>> Right now, I don't see any reason to change the code, as posted, but
>> maybe I am mis-reading?
>>
>
> Sorry, answered the wrong question. Yes, it is the same as above...
> just wandered if we could centralize this test. It might indeed make
> sense to provide general predicates which take a task pointer.
Makes sense to me. I'm leaving this specific patch alone at present.
That said, a quick grep shows only a handful of ia32 references:
./arch/x86/include/asm/compat.h: return is_ia32_task() || is_x32_task();
./arch/x86/ia32/ia32_signal.c: bool ia32 = is_ia32_task();
./arch/x86/kernel/ptrace.c: if (!is_ia32_task())
Would it make sense to make a new predicate or just expand the one
added in 3.4 to take a task_struct parameter? I'm not sure if there'd
be much fallout in converting these from directly checking
current_thread_info to task_thread_info.
It's a small patch either way.
cheers!
will
^ permalink raw reply
* Re: [RFC] net/bridge: port based vlan filtering for bridges
From: Stephen Hemminger @ 2012-04-11 15:38 UTC (permalink / raw)
To: Benjamin LaHaise; +Cc: netdev
In-Reply-To: <20120411153629.GC17739@kvack.org>
On Wed, 11 Apr 2012 11:36:29 -0400
Benjamin LaHaise <bcrl@kvack.org> wrote:
> On Wed, Apr 11, 2012 at 08:30:52AM -0700, Stephen Hemminger wrote:
> > On Wed, 11 Apr 2012 11:10:02 -0400
> > Benjamin LaHaise <bcrl@kvack.org> wrote:
> >
> > > Hello folks,
> > >
> > > Attached is the first stab at a patch to make it possible to filter packets
> > > received from other bridge ports based on the port number. This can be used
> > > to emulate port based VLANs that some switches support.
> > >
> > > The justification for this is a bit interesting. Initially, I had been
> > > filtering packets using firewall rules. Unfortunately, the number of
> > > filter rules becomes impossible to manage when trying to filter traffic
> > > between 100 different ports. CPU overhead of the filters is also a major
> > > problem.
> > >
> > > The particular use-case I'm dealing with is simulating wireless networks
> > > on a system using LXC containers. Each guest has a veth device that is a
> > > member of the bridge, but the topology of which nodes can "hear" each other
> > > changes at runtime.
> > >
> > > Comments/thoughts?
> > >
> >
> > Nak. If firewall doesn't work then implement a better netfilter
> > module.
>
> That still results in the CPU overhead of packet duplication for each and
> every bridge port regardless of the port receiving the packet or not.
> Hmmmm, would a NF_HOOK in should_deliver be okay?
Sure. Having better way to do policy would be great. Just don't want
to have implementations of specific policies in generic code.
^ permalink raw reply
* Re: [RFC] net/bridge: port based vlan filtering for bridges
From: Benjamin LaHaise @ 2012-04-11 15:36 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20120411083052.1ca6a6ef@nehalam.linuxnetplumber.net>
On Wed, Apr 11, 2012 at 08:30:52AM -0700, Stephen Hemminger wrote:
> On Wed, 11 Apr 2012 11:10:02 -0400
> Benjamin LaHaise <bcrl@kvack.org> wrote:
>
> > Hello folks,
> >
> > Attached is the first stab at a patch to make it possible to filter packets
> > received from other bridge ports based on the port number. This can be used
> > to emulate port based VLANs that some switches support.
> >
> > The justification for this is a bit interesting. Initially, I had been
> > filtering packets using firewall rules. Unfortunately, the number of
> > filter rules becomes impossible to manage when trying to filter traffic
> > between 100 different ports. CPU overhead of the filters is also a major
> > problem.
> >
> > The particular use-case I'm dealing with is simulating wireless networks
> > on a system using LXC containers. Each guest has a veth device that is a
> > member of the bridge, but the topology of which nodes can "hear" each other
> > changes at runtime.
> >
> > Comments/thoughts?
> >
>
> Nak. If firewall doesn't work then implement a better netfilter
> module.
That still results in the CPU overhead of packet duplication for each and
every bridge port regardless of the port receiving the packet or not.
Hmmmm, would a NF_HOOK in should_deliver be okay?
-ben
--
"Thought is the essence of where you are now."
^ permalink raw reply
* Re: [RFC] net/bridge: port based vlan filtering for bridges
From: Stephen Hemminger @ 2012-04-11 15:30 UTC (permalink / raw)
To: Benjamin LaHaise; +Cc: netdev
In-Reply-To: <20120411151002.GA17739@kvack.org>
On Wed, 11 Apr 2012 11:10:02 -0400
Benjamin LaHaise <bcrl@kvack.org> wrote:
> Hello folks,
>
> Attached is the first stab at a patch to make it possible to filter packets
> received from other bridge ports based on the port number. This can be used
> to emulate port based VLANs that some switches support.
>
> The justification for this is a bit interesting. Initially, I had been
> filtering packets using firewall rules. Unfortunately, the number of
> filter rules becomes impossible to manage when trying to filter traffic
> between 100 different ports. CPU overhead of the filters is also a major
> problem.
>
> The particular use-case I'm dealing with is simulating wireless networks
> on a system using LXC containers. Each guest has a veth device that is a
> member of the bridge, but the topology of which nodes can "hear" each other
> changes at runtime.
>
> Comments/thoughts?
>
Nak. If firewall doesn't work then implement a better netfilter
module.
^ permalink raw reply
* ipv6 multicast listener on linux box acting as multicast router
From: Massimiliano D'Angelo @ 2012-04-11 15:24 UTC (permalink / raw)
To: netdev
Hi guys,
I would like to have your opinion on a comment in the ip6mr.c file
(kernel 2.6.29.4). The comment follows:
/*
* RFC1584 teaches, that DVMRP/PIM router must deliver packets locally
* not only before forwarding, but after forwarding on all output
* interfaces. It is clear, if mrouter runs a multicasting
* program, it should receive packets not depending to what interface
* program is joined.
* If we will not make it, the program will have to join on all
* interfaces. On the other hand, multihoming host (or router, but
* not mrouter) cannot join to more than one interface - it will
* result in receiving multiple packets.
*/
Does the part "if we will not make it..." mean that such behaviour is
not yet implemented in the kernel? Looking at the code, it seems to me
that it is not yet implemented, but I would like someone to confirm
it.
As an implication, if I have a IPv6 multicast listener on a Linux box
acting as multicast router, do I need to have my application listening
on all the interfaces if I want to receive the multicast messages no
matter what is the interface from which they are received?
Thanks in advance for your help!
Massimiliano
^ permalink raw reply
* Re: [PATCH net-next] rtnetlink & bonding: change args got get_tx_queues
From: Stephen Hemminger @ 2012-04-11 15:20 UTC (permalink / raw)
To: Eric Dumazet
Cc: Ben Hutchings, Jay Vosburgh, Andy Gospodarek, David Miller,
netdev
In-Reply-To: <1334123747.5300.2197.camel@edumazet-glaptop>
On Wed, 11 Apr 2012 07:55:47 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Tue, 2012-04-10 at 21:34 -0700, Stephen Hemminger wrote:
> > Change get_tx_queues, drop unsused arg/return value real_tx_queues,
> > and use return by value (with error) rather than call by reference.
> >
> > Probably bonding should just change to LLTX and the whole get_tx_queues
> > API could disappear!
>
> Absolutely ;)
>
>
It is more complex than that (actually the bonding driver is a mess).
The bonding device is already using Lockless Transmit and transmit queue length
of zero (good), but it then does some queue mapping of it's own which
is unnecessary.
Multiqueue only makes sense if there is a queue, otherwise the skb
can transparently pass through the layered device (vlan, bridge, bond)
and get queued on the real physical device.
Right now, trying to see if there is any impact by just leaving
bond device as single queue.
^ permalink raw reply
* [RFC] net/bridge: port based vlan filtering for bridges
From: Benjamin LaHaise @ 2012-04-11 15:10 UTC (permalink / raw)
To: netdev
Hello folks,
Attached is the first stab at a patch to make it possible to filter packets
received from other bridge ports based on the port number. This can be used
to emulate port based VLANs that some switches support.
The justification for this is a bit interesting. Initially, I had been
filtering packets using firewall rules. Unfortunately, the number of
filter rules becomes impossible to manage when trying to filter traffic
between 100 different ports. CPU overhead of the filters is also a major
problem.
The particular use-case I'm dealing with is simulating wireless networks
on a system using LXC containers. Each guest has a veth device that is a
member of the bridge, but the topology of which nodes can "hear" each other
changes at runtime.
Comments/thoughts?
-ben
---
br_forward.c | 3 +++
br_if.c | 3 +--
br_private.h | 4 ++++
br_sysfs_if.c | 20 ++++++++++++++++++++
4 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/net/bridge/br_forward.c b/net/bridge/br_forward.c
index ee64287..9b106f8 100644
--- a/net/bridge/br_forward.c
+++ b/net/bridge/br_forward.c
@@ -30,6 +30,9 @@ static int deliver_clone(const struct net_bridge_port *prev,
static inline int should_deliver(const struct net_bridge_port *p,
const struct sk_buff *skb)
{
+ struct net_bridge_port *from = br_port_get_rcu(skb->dev);
+ if (from && test_bit(from->port_no, p->filter_ports))
+ return 0;
return (((p->flags & BR_HAIRPIN_MODE) || skb->dev != p->dev) &&
p->state == BR_STATE_FORWARDING);
}
diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
index f603e5b..2f2e595 100644
--- a/net/bridge/br_if.c
+++ b/net/bridge/br_if.c
@@ -183,8 +183,7 @@ static int find_portno(struct net_bridge *br)
struct net_bridge_port *p;
unsigned long *inuse;
- inuse = kcalloc(BITS_TO_LONGS(BR_MAX_PORTS), sizeof(unsigned long),
- GFP_KERNEL);
+ inuse = kcalloc(BR_PORT_LONGS, sizeof(unsigned long), GFP_KERNEL);
if (!inuse)
return -ENOMEM;
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index d7d6fb0..c6fbab0 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -17,6 +17,7 @@
#include <linux/if_bridge.h>
#include <linux/netpoll.h>
#include <linux/u64_stats_sync.h>
+#include <linux/bitops.h>
#include <net/route.h>
#define BR_HASH_BITS 8
@@ -26,6 +27,7 @@
#define BR_PORT_BITS 10
#define BR_MAX_PORTS (1<<BR_PORT_BITS)
+#define BR_PORT_LONGS BITS_TO_LONGS(BR_MAX_PORTS)
#define BR_VERSION "2.3"
@@ -156,6 +158,8 @@ struct net_bridge_port
#ifdef CONFIG_NET_POLL_CONTROLLER
struct netpoll *np;
#endif
+
+ unsigned long filter_ports[BR_PORT_LONGS];
};
#define br_port_exists(dev) (dev->priv_flags & IFF_BRIDGE_PORT)
diff --git a/net/bridge/br_sysfs_if.c b/net/bridge/br_sysfs_if.c
index 6229b62..9d95f6a 100644
--- a/net/bridge/br_sysfs_if.c
+++ b/net/bridge/br_sysfs_if.c
@@ -164,6 +164,24 @@ static BRPORT_ATTR(multicast_router, S_IRUGO | S_IWUSR, show_multicast_router,
store_multicast_router);
#endif
+static int store_add_filter_port(struct net_bridge_port *p, unsigned long v)
+{
+ if (v >= BR_MAX_PORTS)
+ return -EINVAL;
+ set_bit(v, p->filter_ports);
+ return 0;
+}
+static BRPORT_ATTR(add_filter_port, S_IWUSR, NULL, store_add_filter_port);
+
+static int store_remove_filter_port(struct net_bridge_port *p, unsigned long v)
+{
+ if (v >= BR_MAX_PORTS)
+ return -EINVAL;
+ clear_bit(v, p->filter_ports);
+ return 0;
+}
+static BRPORT_ATTR(remove_filter_port, S_IWUSR, NULL, store_remove_filter_port);
+
static struct brport_attribute *brport_attrs[] = {
&brport_attr_path_cost,
&brport_attr_priority,
@@ -184,6 +202,8 @@ static struct brport_attribute *brport_attrs[] = {
#ifdef CONFIG_BRIDGE_IGMP_SNOOPING
&brport_attr_multicast_router,
#endif
+ &brport_attr_add_filter_port,
+ &brport_attr_remove_filter_port,
NULL
};
--
"Thought is the essence of where you are now."
^ permalink raw reply related
* Re: suspicious RCU usage warnings in 3.3.0
From: Meelis Roos @ 2012-04-11 15:08 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel, netdev
In-Reply-To: <20120328.174559.650861844028495880.davem@davemloft.net>
> > Is this the same RCU problem that was fixed after 3.3 (fix a potential
> > rcu_read_lock() imbalance in rt6_fill_node())? My problem does not seem
> > to be ipv6-only, most traces are from IPv6 but some for ip.
>
> It's hard to say because the ipv6 RCU problem causes the warning to
> trigger somewhere away from the ipv6 code that had the RCU locking
> bug.
Tested todays 3.4.0-rc2-00016-ga9e1e53 on the same with flood ping and
still got RCU warning:
[36456.693191]
[36456.712658] ===============================
[36456.767614] [ INFO: suspicious RCU usage. ]
[36456.822588] 3.4.0-rc2-00016-ga9e1e53 #36 Not tainted
[36456.887835] -------------------------------
[36456.942804] include/linux/netpoll.h:70 suspicious rcu_dereference_check() usage!
[36457.040083]
[36457.040089] other info that might help us debug this:
[36457.040098]
[36457.145306]
[36457.145312] RCU used illegally from idle CPU!
[36457.145320] rcu_scheduler_active = 1, debug_locks = 0
[36457.288293] RCU used illegally from extended quiescent state!
[36457.363834] no locks held by swapper/0.
[36457.414221]
[36457.414227] stack backtrace:
[36457.471471] Call Trace:
[36457.503600] [0000000000489834] lockdep_rcu_suspicious+0xd4/0x100
[36457.583727] [00000000006755a8] __netif_receive_skb+0x368/0xa80
[36457.661536] [0000000000675e6c] netif_receive_skb+0x4c/0x60
[36457.734787] [000000000063fd74] tulip_poll+0x3b4/0x6a0
[36457.802327] [00000000006794d8] net_rx_action+0x118/0x1e0
[36457.873299] [00000000004560fc] __do_softirq+0x9c/0x140
[36457.941984] [000000000042b1c4] do_softirq+0x84/0xc0
[36458.007229] [0000000000404a40] __handle_softirq+0x0/0x10
[36458.078199] [000000000042b688] cpu_idle+0x48/0x100
[36458.142314] [0000000000722db8] rest_init+0x160/0x188
[36458.208711] [00000000008c87b0] start_kernel+0x32c/0x33c
[36458.278530] [0000000000722c50] tlb_fixup_done+0x88/0x90
[36458.348346] [0000000000000000] (null)
--
Meelis Roos (mroos@linux.ee)
^ permalink raw reply
* Re: pull request: batman-adv 2012-04-11
From: David Miller @ 2012-04-11 14:50 UTC (permalink / raw)
To: gmazzurco89-Re5JQEeQqe8AvxtiuMwx3w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <4F85989F.6030802-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Gioacchino Mazzurco <gmazzurco89-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Wed, 11 Apr 2012 16:43:43 +0200
> It is not like that for a lot of batman-adv users that works with
> embedded devices where even 10KB makes the dfference
Ok, but you also have the option of making it a seperate module
too.
Right now it's an all or nothing choice. Once you make a Kconfig
decision, later it's harder to rebuild the kernel to fix a mistake
than to simply load the module in question.
^ permalink raw reply
* Re: [net-next PATCH v1 3/7] net: add fdb generic dump routine
From: John Fastabend @ 2012-04-11 14:46 UTC (permalink / raw)
To: Ben Hutchings
Cc: mst, stephen.hemminger, davem, hadi, jeffrey.t.kirsher, netdev,
gregory.v.rose, krkumar2, sri
In-Reply-To: <1334115901.7150.371.camel@deadeye>
On 4/10/2012 8:45 PM, Ben Hutchings wrote:
> On Mon, 2012-04-09 at 15:00 -0700, John Fastabend wrote:
>> This adds a generic dump routine drivers can call. It
>> should be sufficient to handle any bridging model that
>> uses the unicast address list. This should be most SR-IOV
>> enabled NICs.
> [...]
>> +static int nlmsg_populate_fdb(struct sk_buff *skb,
>> + struct netlink_callback *cb,
>> + struct net_device *dev,
>> + int *idx,
>> + struct netdev_hw_addr_list *list)
>> +{
>> + struct netdev_hw_addr *ha;
>> + struct ndmsg *ndm;
>> + struct nlmsghdr *nlh;
>> + u32 pid, seq;
>> +
>> + pid = NETLINK_CB(cb->skb).pid;
>> + seq = cb->nlh->nlmsg_seq;
>> +
>> + list_for_each_entry(ha, &list->list, list) {
>> + if (*idx < cb->args[0])
>> + goto skip;
>> +
>> + nlh = nlmsg_put(skb, pid, seq,
>> + RTM_NEWNEIGH, sizeof(*ndm), NLM_F_MULTI);
>> + if (!nlh)
>> + break;
>
> This break is effectively return 0, but shouldn't we return an error?
> In practice this does no harm because any subsequent invocation of
> nlmsg_populate_fdb() for the same skb is also going to fail here with no
> change to *idx. But it would be more obviously correct to return an
> error.
>
sure returning -EMSGSIZE seems to be inline with rtnl_fill_ifinfo and
easier to read.
> [...]
>> + }
>> + return 0;
>> +nla_put_failure:
>> + nlmsg_cancel(skb, nlh);
>> + return -ENOMEM;
>> +}
> [...]
>
also might be better to return -EMSGSIZE here as well. It seems to be
more inline with convention.
.John
^ permalink raw reply
* Re: [net-next PATCH v1 2/7] net: addr_list: add exclusive dev_uc_add and dev_mc_add
From: John Fastabend @ 2012-04-11 14:46 UTC (permalink / raw)
To: Ben Hutchings
Cc: mst, stephen.hemminger, davem, hadi, jeffrey.t.kirsher, netdev,
gregory.v.rose, krkumar2, sri
In-Reply-To: <1334115190.7150.365.camel@deadeye>
On 4/10/2012 8:33 PM, Ben Hutchings wrote:
> On Mon, 2012-04-09 at 15:00 -0700, John Fastabend wrote:
>> This adds a dev_uc_add_excl() and dev_mc_add_excl() calls
>> similar to the original dev_{uc|mc}_add() except it sets
>> the global bit and returns -EEXIST for duplicat entires.
>>
>> This is useful for drivers that support SR-IOV, macvlan
>> devices and any other devices that need to manage the
>> unicast and multicast lists.
> [...]
>> +/**
>> + * dev_mc_add_excl - Add a global secondary multicast address
>> + * @dev: device
>> + * @addr: address to add
>> + */
>> +int dev_mc_add_excl(struct net_device *dev, unsigned char *addr)
>> +{
>> + struct netdev_hw_addr *ha;
>> + int err;
>> +
>> + netif_addr_lock_bh(dev);
>> + list_for_each_entry(ha, &dev->mc.list, list) {
>> + if (!memcmp(ha->addr, addr, dev->addr_len) &&
>> + ha->type == NETDEV_HW_ADDR_T_UNICAST) {
>> + err = -EEXIST;
>> + goto out;
>> + }
>> + }
>> + err = __hw_addr_create_ex(&dev->mc, addr, dev->addr_len,
>> + NETDEV_HW_ADDR_T_UNICAST, true);
> [...]
>
> The address types are wrong. But do we even need this function yet?
>
> Ben.
>
macvlan wants to manage multicast addresses as well. Good catch thanks.
.John
^ permalink raw reply
* Re: [net-next PATCH v1 1/7] net: add generic PF_BRIDGE:RTM_ FDB hooks
From: John Fastabend @ 2012-04-11 14:45 UTC (permalink / raw)
To: Ben Hutchings
Cc: roprabhu, mst, stephen.hemminger, davem, hadi, jeffrey.t.kirsher,
netdev, gregory.v.rose, krkumar2, sri
In-Reply-To: <1334114599.7150.361.camel@deadeye>
On 4/10/2012 8:23 PM, Ben Hutchings wrote:
> On Mon, 2012-04-09 at 15:00 -0700, John Fastabend wrote:
> [...]
>> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
>> index 1f77540..05822e5 100644
>> --- a/include/linux/netdevice.h
>> +++ b/include/linux/netdevice.h
> [...]
>> @@ -905,6 +906,19 @@ struct netdev_fcoe_hbainfo {
>> * feature set might be less than what was returned by ndo_fix_features()).
>> * Must return >0 or -errno if it changed dev->features itself.
>> *
>> + * int (*ndo_fdb_add)(struct ndmsg *ndm, struct net_device *dev,
>> + * unsigned char *addr, u16 flags)
>> + * Adds an FDB entry to dev for addr. The ndmsg contains flags to indicate
>> + * if the dev->master FDB should be updated or the devices internal FDB.
>
> I don't think the second sentence is helpful, as rtnl_fdb_add() will
> take care of those flags.
>
>> + * int (*ndo_fdb_del)(struct ndmsg *ndm, struct net_device *dev,
>> + * unsigned char *addr)
>> + * Deletes the FDB entry from dev coresponding to addr. The ndmsg
>> + * contains flags to indicate if the dev->master FDB should be
>> + * updated or the devices internal FDB.
>
> Similarly here.
agreed neither seem particularly helpful I'll remove them.
>
>> + * int (*ndo_fdb_dump)(struct sk_buff *skb, struct netlink_callback *cb,
>> + * struct net_device *dev, int idx)
>> + * Used to add FDB entries to dump requests. Implementers should add
>> + * entries to skb and update idx with the number of entries.
>> */
> [...
>> --- a/net/core/rtnetlink.c
>> +++ b/net/core/rtnetlink.c
> [...]
>> +static int rtnl_fdb_add(struct sk_buff *skb, struct nlmsghdr *nlh, void *arg)
>> +{
> [...]
>> + err = -EOPNOTSUPP;
>
> So if NTF_MASTER and NTF_SELF are both set, we can quietly fall back to
> just setting one FDB? Not sure that's really desirable though
>
It makes it easier to keep an embedded agent and the sw bridge in
sync if setting both flags adds the entry to both the SW bridge and
embedded bridge. But the error case gets a bit tricky as your comments
below indicate.
>> + /* Support fdb on master device the net/bridge default case */
>> + if ((!ndm->ndm_flags || ndm->ndm_flags & NTF_MASTER) &&
>> + (dev->priv_flags & IFF_BRIDGE_PORT)) {
>> + struct net_device *master = dev->master;
>> +
>> + if (master->netdev_ops->ndo_fdb_add)
>
> This operation is surely going to be mandatory for bridge devices, so
> this check should be omitted or changed to a BUG_ON().
I'll just remove the check.
>
>> + err = master->netdev_ops->ndo_fdb_add(ndm, dev, addr,
>> + nlh->nlmsg_flags);
>
> Shoudn't we return early on error?
Agreed better to return an err here.
>
>> + }
>> +
>> + /* Embedded bridge, macvlan, and any other device support */
>> + if ((ndm->ndm_flags & NTF_SELF) &&
>> + dev->netdev_ops->ndo_fdb_add)
>
> Error if !dev->netdev_ops->ndo_fdb_add.
>
>> + err = dev->netdev_ops->ndo_fdb_add(ndm, dev, addr,
>> + nlh->nlmsg_flags);
>
> Wonder what we should do on error here if we've already successfully
> called ndo_fdb_add on the master? Should we try to roll back the first
> addition?
>
The problem with rolling back is the table is likely already updated and
traffic may already be being forwarded. So I think in this case the user
will have to query the device to learn what failed. It seems like the
simplest way to handle this. I think it is unwanted to have traffic being
forwarded one way for a short period of time then rolled back.
The other idea I just had is we could clear the NTF_ bit in ndm_flags after
the successful add, del command. I believe the nlmsg gets sent back to the
user on error I would need to check on this.
>> + return err;
>> +}
>> +
>> +static int rtnl_fdb_del(struct sk_buff *skb, struct nlmsghdr *nlh, void *arg)
>> +{
> [...]
>> + err = -EOPNOTSUPP;
>> +
>> + /* Support fdb on master device the net/bridge default case */
>> + if ((!ndm->ndm_flags || ndm->ndm_flags & NTF_MASTER) &&
>> + (dev->priv_flags & IFF_BRIDGE_PORT)) {
>> + struct net_device *master = dev->master;
>> +
>> + if (master->netdev_ops->ndo_fdb_del)
>> + err = master->netdev_ops->ndo_fdb_del(ndm, dev, addr);
>> + }
>> +
>> + /* Embedded bridge, macvlan, and any other device support */
>> + if ((ndm->ndm_flags & NTF_SELF) &&
>> + dev->netdev_ops->ndo_fdb_del)
>> + err = dev->netdev_ops->ndo_fdb_del(ndm, dev, addr);
>> + return err;
>> +}
> [...]
>
> This has the same issues.
>
same comment as above
> Ben.
>
^ permalink raw reply
* Re: pull request: batman-adv 2012-04-11
From: Gioacchino Mazzurco @ 2012-04-11 14:43 UTC (permalink / raw)
To: The list for a Better Approach To Mobile Ad-hoc Networking
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, David Miller
In-Reply-To: <20120411.103933.846397076858317541.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
It is not like that for a lot of batman-adv users that works with
embedded devices where even 10KB makes the dfference
On 04/11/12 16:39, David Miller wrote:
> From: Antonio Quartulli <ordex-GaUfNO9RBHfsrOwW+9ziJQ@public.gmane.org>
> Date: Wed, 11 Apr 2012 16:31:03 +0200
>
>> Actually we have either the Kconfig option (for binary size purposes) AND a
>> boolean attribute in our soft_interface sysfs path (to dynamically turn the
>> bridge loop avoidance ON and OFF as you were suggesting).
>
> Distributions are just going to turn on everything, so for %99.999 of
> users you really aren't saving anything.
^ permalink raw reply
* Re: [RFC] net/hsr: Add support for IEC 62439-3 High-availability Seamless Redundancy
From: Arvid Brodin @ 2012-04-11 14:39 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Ben Hutchings, David Miller, netdev@vger.kernel.org,
balferreira@googlemail.com
In-Reply-To: <20120410182847.45e47c5e@nehalam.linuxnetplumber.net>
On 2012-04-11 03:28, Stephen Hemminger wrote:
>
>> 3) My feeble suggestion to cast icmp_hdr() to (char *) is of course even worse (it doesn't
>> even avoid the erroneous cast in the first place).
>>
>> So what do we do?
>>
>
> Reading Documentation/unalgined-memory-access.txt suggests that you
> probably should copy the skb before passing up the stack (if necessary).
> That is safe (but slightly slower).
Ok, so my patch does the right thing then? I.e. if no HAVE_EFFICIENT_UNALIGNED_ACCESS and
the user does not choose to pad the HSR tag (with NONSTANDARD_HSR), we memmove the payload
(look in hsr_rcv()).
Or do you want me to remove the option to pad the HSR tag to get rid of the memmove if we
don't HAVE_EFFICIENT_UNALIGNED_ACCESS?
--
Arvid Brodin
Enea Services Stockholm AB - since February 16 a part of Xdin in the Alten Group. Soon we
will be working under the common brand name Xdin. Read more at www.xdin.com.
^ permalink raw reply
* Re: [B.A.T.M.A.N.] pull request: batman-adv 2012-04-11
From: David Miller @ 2012-04-11 14:39 UTC (permalink / raw)
To: ordex; +Cc: netdev, b.a.t.m.a.n
In-Reply-To: <20120411143102.GE19365@ritirata.org>
From: Antonio Quartulli <ordex@autistici.org>
Date: Wed, 11 Apr 2012 16:31:03 +0200
> Actually we have either the Kconfig option (for binary size purposes) AND a
> boolean attribute in our soft_interface sysfs path (to dynamically turn the
> bridge loop avoidance ON and OFF as you were suggesting).
Distributions are just going to turn on everything, so for %99.999 of
users you really aren't saving anything.
^ permalink raw reply
* Re: [net-next PATCH v1 7/7] macvlan: add FDB bridge ops and new macvlan mode
From: John Fastabend @ 2012-04-11 14:32 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Sridhar Samudrala, roprabhu, stephen.hemminger, davem, hadi,
bhutchings, jeffrey.t.kirsher, netdev, gregory.v.rose, krkumar2
In-Reply-To: <20120411080239.GB8562@redhat.com>
On 4/11/2012 1:02 AM, Michael S. Tsirkin wrote:
> On Tue, Apr 10, 2012 at 06:42:47PM -0700, John Fastabend wrote:
>> On 4/10/2012 5:46 PM, Sridhar Samudrala wrote:
>>> On 4/10/2012 8:35 AM, John Fastabend wrote:
>>>> On 4/10/2012 8:30 AM, Michael S. Tsirkin wrote:
>>>>> On Tue, Apr 10, 2012 at 08:26:21AM -0700, John Fastabend wrote:
>>>>>> On 4/10/2012 7:35 AM, Michael S. Tsirkin wrote:
>>>>>>> On Tue, Apr 10, 2012 at 07:25:58AM -0700, John Fastabend wrote:
>>>>>>>>> Hmm okay, but this would mean we should convert
>>>>>>>>> MACVLAN_MODE_PASSTHRU_NOPROMISC to something
>>>>>>>>> that can combined with all modes. E.g.
>>>>>>>>> MACVLAN_MODE_BRIDGE | MACVLAN_MODE_FLAG_XXXXX
>>>>>>>>>
>>>>>>>>> and document that it does not promise to flood
>>>>>>>>> multicast.
>>>>>>>>>
>>>>>>>> How about changing MACVLAN_MODE_PASSTHRU_NOPROMISC -> MACVLAN_MODE_NOPORMISC
>>>>>>>> for this patch. Then a follow on series can rework bridge
>>>>>>>> and VEPA to use it as well.
>>>>>>> Right. We probably need a better name if it's going to
>>>>>>> affect other things besides promisc though.
>>>>>>>
>>>>>> how about MACVLAN_MODE_FDBFLAG?
>>>>> The idea being that no one figures out what this means so
>>>>> no one will make any wrong assumptions? ;)
>>>>>
>>>> Well its a flag to enable the FDB (forwarding database) ops
>>>> and skip dev_set_promisc() on passthru mode. Any better ideas?
>>>> Maybe MACVLAN_MODE_FDBENABLE or MACVLAN_MODE_MANAGE_FDB?
>>> Do we need to introduce another mode? I think this patch is enabling passthru mode without the need
>>> to put the underlying device in promiscuous mode. So basically we can consider this patch as
>>> an optimization.
>>>
>>> Thanks
>>> Sridhar
>>>
>>
>> Sridhar, Michael,
>>
>> After thinking about this a bit I would propose keeping this
>> patch as is. Or if we prefer I can make this a flag but I don't
>> think that helps much. passthru mode is the only macvlan mode
>> that calls dev_set_promiscuity(). Either way I think this mode
>> or flag should _only_ toggle the call to dev_set_promiscuity().
>>
>> Setting multicast dev->flag IFF_ALLMULTI seems to be a completely
>> separate optimization that we can work with a follow up patch.
>>
>> Any thoughts?
>>
>> Thanks for the feedback,
>> John
>
> I agree it's a separate optimization. But if we let the
> number of supported modes explode
> (MACVLAN_MODE_PASSTHRU_NOPROMISC MACVLAN_MODE_PASSTHRU_NOALLMULTI
> ....) supporting them all and combinations thereof might become a problem.
>
> I'm looking for an interface solution that will limit this
> overhead without breaking existing setups.
>
I'm going to respin this series today. I'll try to rework this with
a flags field so that we can set nopromisc and noallmutli using flags
and not have the supported mode space explode.
>
> One idea was to have a flag that says basically "really obey device
> configuration". Yes if we do this we can then split the support to
> multiple patches and consider each individual one a bugfix, though if we
> put a known broken solution in 3.5 there's a danger that someone will
> come to depend on the broken behaviour. Other ideas?
>
>
This sound reasonable.
Thanks,
John
^ permalink raw reply
* Re: pull request: batman-adv 2012-04-11
From: Antonio Quartulli @ 2012-04-11 14:31 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <20120411.095809.861355939666821335.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 992 bytes --]
On Wed, Apr 11, 2012 at 09:58:09 -0400, David Miller wrote:
> From: Antonio Quartulli <ordex-GaUfNO9RBHfsrOwW+9ziJQ@public.gmane.org>
> Date: Wed, 11 Apr 2012 15:03:03 +0200
>
> > git://git.open-mesh.org/linux-merge.git tags/batman-adv-for-davem
> >
> > for you to fetch changes up to 7a5cc24277b57ce38eb0afa6634b71d4d5cc671e:
> >
> > batman-adv: add bridge loop avoidance compile option (2012-04-11 14:29:00 +0200)
>
> Pulled, but I think the way you're doing the bridge loop avoidance stuff
> is wrong.
>
> Don't use a Kconfig option, use a sysctl to turn the behavior off or on
> at runtime instead.
Hello David and thank you for your feedback.
Actually we have either the Kconfig option (for binary size purposes) AND a
boolean attribute in our soft_interface sysfs path (to dynamically turn the
bridge loop avoidance ON and OFF as you were suggesting).
Regards,
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH] tcp: avoid order-1 allocations on wifi and tx path
From: David Miller @ 2012-04-11 14:11 UTC (permalink / raw)
To: eric.dumazet; +Cc: marc, Larry.Finger, bhutchings, linux-wireless, netdev
In-Reply-To: <1334125848.5300.2330.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 11 Apr 2012 08:30:48 +0200
> Marc Merlin reported many order-1 allocations failures in TX path on its
> wireless setup, that dont make any sense with MTU=1500 network, and non
> SG capable hardware.
>
> After investigation, it turns out TCP uses sk_stream_alloc_skb() and
> used as a convention skb_tailroom(skb) to know how many bytes of data
> payload could be put in this skb (for non SG capable devices)
>
> Note : these skb used kmalloc-4096 (MTU=1500 + MAX_HEADER +
> sizeof(struct skb_shared_info) being above 2048)
>
> Later, mac80211 layer need to add some bytes at the tail of skb
> (IEEE80211_ENCRYPT_TAILROOM = 18 bytes) and since no more tailroom is
> available has to call pskb_expand_head() and request order-1
> allocations.
>
> This patch changes sk_stream_alloc_skb() so that only
> sk->sk_prot->max_header bytes of headroom are reserved, and use a new
> skb field, avail_size to hold the data payload limit.
>
> This way, order-0 allocations done by TCP stack can leave more than 2 KB
> of tailroom and no more allocation is performed in mac80211 layer (or
> any layer needing some tailroom)
>
> avail_size is unioned with mark/dropcount, since mark will be set later
> in IP stack for output packets. Therefore, skb size is unchanged.
>
> Reported-by: Marc MERLIN <marc@merlins.org>
> Tested-by: Marc MERLIN <marc@merlins.org>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied and queued up for -stable, thanks Eric.
^ permalink raw reply
* Re: [PATCH] tcp: avoid order-1 allocations on wifi and tx path
From: David Miller @ 2012-04-11 14:12 UTC (permalink / raw)
To: eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w
Cc: marc-xnduUnryOU1AfugRpC6u6w, Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ,
bhutchings-s/n/eUQHGBpZroRs9YW3xA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1334129882.5300.2539.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Wed, 11 Apr 2012 09:38:02 +0200
> David, I forgot to say this should be backported to 3.2 & 3.3
Yep.
> commit 87fb4b7b533073 (net: more accurate skb truesize) did the
> placement of skb_shared_info at the end of skb head, so
> sk_stream_alloc_skb() had to reserve more room so that tailroom stayed
> at MSS
Will keep that in mind, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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
* Re: [PATCH] net: allow pskb_expand_head() to get maximum tailroom
From: David Miller @ 2012-04-11 14:11 UTC (permalink / raw)
To: eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w
Cc: marc-xnduUnryOU1AfugRpC6u6w, Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ,
bhutchings-s/n/eUQHGBpZroRs9YW3xA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1334124519.5300.2246.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Wed, 11 Apr 2012 08:08:39 +0200
> Marc Merlin reported many order-1 allocations failures in TX path on its
> wireless setup, that dont make any sense with MTU=1500 network, and non
> SG capable hardware.
>
> Turns out part of the problem comes from pskb_expand_head() not using
> ksize() to get exact head size given by kmalloc(). Doing the same thing
> than __alloc_skb() allows more tailroom in skb and can prevent future
> reallocations.
>
> As a bonus, struct skb_shared_info becomes cache line aligned.
>
> Reported-by: Marc MERLIN <marc-xnduUnryOU1AfugRpC6u6w@public.gmane.org>
> Tested-by: Marc MERLIN <marc-xnduUnryOU1AfugRpC6u6w@public.gmane.org>
> Signed-off-by: Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Applied and queued up for -stable.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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
* Re: [patch net-next 1/5] team: add support for per-port options
From: David Miller @ 2012-04-11 13:58 UTC (permalink / raw)
To: jpirko; +Cc: netdev, eric.dumazet
In-Reply-To: <20120411054023.GA1955@minipsycho>
From: Jiri Pirko <jpirko@redhat.com>
Date: Wed, 11 Apr 2012 07:43:51 +0200
> Tue, Apr 10, 2012 at 08:33:56PM CEST, davem@davemloft.net wrote:
>>From: Jiri Pirko <jpirko@redhat.com>
>>Date: Tue, 10 Apr 2012 17:15:42 +0200
>>
>>> @@ -81,7 +81,16 @@ EXPORT_SYMBOL(team_port_set_team_mac);
>>> * Options handling
>>> *******************/
>>>
>>> -struct team_option *__team_find_option(struct team *team, const char *opt_name)
>>> +struct team_option_inst { /* One for each option instance */
>>> + struct list_head list;
>>> + struct team_option *option;
>>> + struct team_port *port; /* != NULL if per-port */
>>> + bool changed;
>>> + bool removed;
>>> +};
>>> +
>>
>>All this indirection... just simply embed struct team_option into
>>struct team_option_inst instead of using a pointer, and allocate a
>>full team_option_inst where you currently memdup in the options.
>
> Well the list of options is needed alone. When port is added/removed, this list
> gets iterated over and instances are created/deleted. Therefore I put
> pointer to option to option instance struct to save memory (and also to
> be nicer)
Fair enough, I'll apply this series, thanks.
^ permalink raw reply
* Re: pull request: batman-adv 2012-04-11
From: David Miller @ 2012-04-11 13:58 UTC (permalink / raw)
To: ordex-GaUfNO9RBHfsrOwW+9ziJQ
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <20120411130301.GD19365-E/2OGukznS5g9hUCZPvPmw@public.gmane.org>
From: Antonio Quartulli <ordex-GaUfNO9RBHfsrOwW+9ziJQ@public.gmane.org>
Date: Wed, 11 Apr 2012 15:03:03 +0200
> git://git.open-mesh.org/linux-merge.git tags/batman-adv-for-davem
>
> for you to fetch changes up to 7a5cc24277b57ce38eb0afa6634b71d4d5cc671e:
>
> batman-adv: add bridge loop avoidance compile option (2012-04-11 14:29:00 +0200)
Pulled, but I think the way you're doing the bridge loop avoidance stuff
is wrong.
Don't use a Kconfig option, use a sysctl to turn the behavior off or on
at runtime instead.
^ 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