* [PATCH next v2 1/7] dev: Add netif_get_l3_dev() helper
From: Mahesh Bandewar @ 2016-03-09 21:49 UTC (permalink / raw)
To: David Miller
Cc: Mahesh Bandewar, Eric Dumazet, netdev, Tim Hockin, Alex Pollitt,
Matthew Dupre
From: Mahesh Bandewar <maheshb@google.com>
This patch adds a l3_dev to net_device struct and a helper
function to retrieve it. During L3 ingress packet processing,
this device will be used and should serve the current purpose
of skb->dev. Since l3_dev is initialized to self; l3_dev should
be pointing to skb->dev so the normal packet processing is
neither altered nor should incur any additional cost (as it
resides in the RX cache line).
Signed-off-by: Mahesh Bandewar <maheshb@google.com>
CC: Eric Dumazet <edumazet@google.com>
CC: Tim Hockin <thockin@google.com>
CC: Alex Pollitt <alex.pollitt@metaswitch.com>
CC: Matthew Dupre <matthew.dupre@metaswitch.com>
---
include/linux/netdevice.h | 6 ++++++
net/core/dev.c | 1 +
2 files changed, 7 insertions(+)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index e52077ffe5ed..1cf7e8d61043 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1738,6 +1738,7 @@ struct net_device {
unsigned long gro_flush_timeout;
rx_handler_func_t __rcu *rx_handler;
void __rcu *rx_handler_data;
+ struct net_device *l3_dev;
#ifdef CONFIG_NET_CLS_ACT
struct tcf_proto __rcu *ingress_cl_list;
@@ -4085,6 +4086,11 @@ static inline void netif_keep_dst(struct net_device *dev)
dev->priv_flags &= ~(IFF_XMIT_DST_RELEASE | IFF_XMIT_DST_RELEASE_PERM);
}
+static inline struct net_device *netif_get_l3_dev(struct net_device *dev)
+{
+ return dev->l3_dev;
+}
+
extern struct pernet_operations __net_initdata loopback_net_ops;
/* Logging, debugging and troubleshooting/diagnostic helpers. */
diff --git a/net/core/dev.c b/net/core/dev.c
index edb7179bc051..c4023a68cdc1 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -7463,6 +7463,7 @@ struct net_device *alloc_netdev_mqs(int sizeof_priv, const char *name,
if (!dev->ethtool_ops)
dev->ethtool_ops = &default_ethtool_ops;
+ dev->l3_dev = dev;
nf_hook_ingress_init(dev);
return dev;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH next v2 0/7] Introduce l3_dev pointer for L3 processing
From: Mahesh Bandewar @ 2016-03-09 21:49 UTC (permalink / raw)
To: David Miller; +Cc: Mahesh Bandewar, Eric Dumazet, netdev
From: Mahesh Bandewar <maheshb@google.com>
One of the major request (for enhancement) that I have received
from various users of IPvlan in L3 mode is its inability to handle
IPtables.
While looking at the code and how we handle ingress, the problem
can be attributed to the asymmetry in the way packets get processed
for IPvlan devices configured in L3 mode. L3 mode is supposed to
be restrictive and all the L3 decisions need to be taken for the
traffic in master's ns. This does happen as expected for egress
traffic however on ingress traffic, the IPvlan packet-handler
changes the skb->dev and this forces packet to be processed with
the IPvlan slave and it's associated ns. This causes above mentioned
problem and few other which are not yet reported / attempted. e.g.
IPsec with L3 mode or even ingress routing.
This could have been solved if we had a way to handover packet to
slave and associated ns after completing the L3 phase. This is a
non-trivial issue to fix especially looking at IPsec code.
This patch series attempts to solve this problem by introducing the
device pointer l3_dev which resides in net_device structure in the
RX cache line. We initialize the l3_dev to self. This would mean
there is no complex logic to when-and-how-to initialize it. Now
the stack will use this dev pointer during the L3 phase. This should
not alter any existing properties / behavior and also there should
not be any additional penalties since it resides in the same RX
cache line.
Now coming back to IPvlan setup. The typical IPvlan L3 setup where
master is in default-ns while the slaves are put inside different
(slave) net-ns. During the initialization phase, the driver can
make l3_dev for each slave to point to its master-device. This will
solve the current IPT problem as well as make the packet processing
symmetric from stack perspective. For all other packet processing
since dev->l3_dev is same as dev, there should not be any behavioral
or functional change.
Mahesh Bandewar (7):
dev: Add netif_get_l3_dev() helper
dev: Update packet dispatcher to pass l3_dev as an input device
ipv4: Use l3_dev for L3 ingress processing
ipv6: Use l3_dev for L3 ingress processing
raw: Use l3_dev for L3 ingress raw packet delivery
xfrm: Use l3_dev for xfrm policy checks.
ipvlan: Implement L3-symmetric mode.
drivers/net/ipvlan/ipvlan_main.c | 16 +++++++++-------
include/linux/netdevice.h | 6 ++++++
include/net/xfrm.h | 2 +-
net/core/dev.c | 10 +++++++---
net/ipv4/ip_input.c | 12 +++++++-----
net/ipv4/ip_options.c | 3 ++-
net/ipv4/raw.c | 11 +++++------
net/ipv6/ip6_input.c | 14 ++++++++------
net/ipv6/raw.c | 2 +-
net/ipv6/route.c | 7 ++++---
net/xfrm/xfrm_policy.c | 4 ++--
11 files changed, 52 insertions(+), 35 deletions(-)
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply
* Re: [net-next PATCH 3/4] vxlan: Enforce IP ID verification on outer headers
From: Alexander Duyck @ 2016-03-09 21:49 UTC (permalink / raw)
To: David Miller; +Cc: Jesse Gross, Alex Duyck, Or Gerlitz, Netdev
In-Reply-To: <20160309.160225.262235291935624404.davem@davemloft.net>
On Wed, Mar 9, 2016 at 1:02 PM, David Miller <davem@davemloft.net> wrote:
> From: Jesse Gross <jesse@kernel.org>
> Date: Mon, 7 Mar 2016 15:42:59 -0800
>
>> On Mon, Mar 7, 2016 at 3:06 PM, Alex Duyck <aduyck@mirantis.com> wrote:
>>> On Mon, Mar 7, 2016 at 11:09 AM, David Miller <davem@davemloft.net> wrote:
>>>> From: Or Gerlitz <gerlitz.or@gmail.com>
>>>> Date: Mon, 7 Mar 2016 20:05:20 +0200
>>>>
>>>>> On Mon, Mar 7, 2016 at 7:22 PM, Alexander Duyck <aduyck@mirantis.com> wrote:
>>>>>> This change enforces the IP ID verification on outer headers. As a result
>>>>>> if the DF flag is not set on the outer header we will force the flow to be
>>>>>> flushed in the event that the IP ID is out of sequence with the existing
>>>>>> flow.
>>>>>
>>>>> Can you please state the precise requirement for aggregation w.r.t IP
>>>>> IDs here? and point to where/how this is enforced, e.g for
>>>>> non-tunneled TCP GRO-ing?
>>>>
>>>> I also didn't see a nice "PATCH 0/4" posting explaining this series and
>>>> I'd really like to see that.
>>>
>>> Sorry about that. I forgot to add the cover page when I sent this.
>>>
>>> The enforcement is coming from the IP and TCP layers. If you take a
>>> look in inet_gro_receive we have the NAPI_GRO_CB(p)->flush_id value
>>> being populated based on the difference between the expected ID and
>>> the received one. So for IPv4 we overwrite it, and for IPv6 we set it
>>> to 0. The only consumer currently using it is TCP in tcp_gro_receive.
>>> The problem is with tunnels we lose the data for the outer when the
>>> inner overwrites it, as a result we can put whatever we want currently
>>> in the outer IP ID and it will be accepted.
>>>
>>> The patch set is based off of a conversation several of us had on the
>>> list about doing TSO for tunnels and the fact that the IP IDs for the
>>> outer header have to advance. It makes it easier for me to validate
>>> that I am doing things properly if GRO doesn't destroy the IP ID data
>>> for the outer headers.
>>
>> In net/ipv4/af_inet.c:inet_gro_receive() there is the following
>> comment above where NAPI_GRO_CB(p)->flush_id is set:
>>
>> /* Save the IP ID check to be included later when we get to
>> * the transport layer so only the inner most IP ID is checked.
>> * This is because some GSO/TSO implementations do not
>> * correctly increment the IP ID for the outer hdrs.
>> */
>>
>> There was a long discussion about this a couple years ago and the
>> conclusion was that it is the inner IP ID is really the important one
>> in the case of encapsulation. Obviously, things like TCP/IP header
>> compression don't apply to the outer encapsulation header.
>
> That's how I remember the conversation going as wel...
Given that then, how would you feel about a software scheme to use
existing TSO support on devices to support UDP/GRE tunnel TSO by
pre-computing the values for the outer headers and then having those
duplicated on TSO frames?
This is kind of what got me started down the path of validating the
outer IP ID. If we are okay with UDP or GRE encapsulated tunnels
using the same IP ID for the outer headers then I should be able to
code up something in software so that we can get more devices
supporting tunnel TSO offload for tunnels.
- Alex
^ permalink raw reply
* Re: [net-next PATCH 2/7] mlx4: use napi_consume_skb API to get bulk free operations
From: Jesper Dangaard Brouer @ 2016-03-09 21:47 UTC (permalink / raw)
To: Alexander Duyck
Cc: David Miller, Netdev, eugenia, Alexei Starovoitov, Saeed Mahameed,
Or Gerlitz, brouer
In-Reply-To: <CAKgT0Ue2qRhJr2_7q3ih9wNQ3SAwVuzf8-YCctS_3So=9m8bXw@mail.gmail.com>
On Wed, 9 Mar 2016 13:43:59 -0800
Alexander Duyck <alexander.duyck@gmail.com> wrote:
> On Wed, Mar 9, 2016 at 1:36 PM, Jesper Dangaard Brouer
> <brouer@redhat.com> wrote:
> > On Wed, 09 Mar 2016 16:03:20 -0500 (EST)
> > David Miller <davem@davemloft.net> wrote:
> >
> >> From: Alexander Duyck <alexander.duyck@gmail.com>
> >> Date: Wed, 9 Mar 2016 08:47:58 -0800
> >>
> >> > On Wed, Mar 9, 2016 at 3:00 AM, Jesper Dangaard Brouer
> >> > <brouer@redhat.com> wrote:
> >> >> Passing the budget down was Alex'es design. Axel any thoughts?
> >> >
> >> > I'd say just use dev_consume_skb_any in the bulk free instead of
> >> > dev_consume_skb_irq. This is slow path, as you said, so it shouldn't
> >> > come up often.
> >>
> >> Agreed.
> >>
> >> >> I do wonder how expensive this check is... as it goes into a code
> >> >> hotpath, which is very unlikely. The good thing would be, that we
> >> >> handle if buggy drivers call this function from a none softirq context
> >> >> (as these bugs could be hard to catch).
> >> >>
> >> >> Can netpoll ever be called from softirq or with BH disabled? (It
> >> >> disables IRQs, which would break calling kmem_cache_free_bulk).
> >> >
> >> > It is better for us to switch things out so that the napi_consume_skb
> >> > is the fast path with dev_consume_skb_any as the slow. There are too
> >> > many scenarios where we could be invoking something that makes use of
> >> > this within the Tx path so it is probably easiest to just solve it
> >> > that way so we don't have to deal with it again in the future.
> >>
> >> Indeed.
> >
> > So, if I understand you correctly, then we drop the budget parameter
> > and check for in_softirq(), like:
> >
> > diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> > index 7af7ec635d90..a3c61a9b65d2 100644
> > --- a/net/core/skbuff.c
> > +++ b/net/core/skbuff.c
> > @@ -796,14 +796,14 @@ void __kfree_skb_defer(struct sk_buff *skb)
> > _kfree_skb_defer(skb);
> > }
> >
> > -void napi_consume_skb(struct sk_buff *skb, int budget)
> > +void napi_consume_skb(struct sk_buff *skb)
> > {
> > if (unlikely(!skb))
> > return;
> >
> > - /* if budget is 0 assume netpoll w/ IRQs disabled */
> > - if (unlikely(!budget)) {
> > - dev_consume_skb_irq(skb);
> > + /* Handle if not called from NAPI context, and netpoll invocation */
> > + if (unlikely(!in_softirq())) {
> > + dev_consume_skb_any(skb);
> > return;
> > }
> >
>
> No. We still need to have the budget value. What we do though is
> have that feed into dev_consume_skb_any.
>
> The problem with using in_softirq is that it will trigger if softirqs
> are just disabled so there are more possible paths where it is
> possible. For example the transmit path has bottom halves disabled so
> I am pretty sure it might trigger this as well. We want this to only
> execute when we are running from a NAPI polling routine with a
> non-zero budget.
What about using in_serving_softirq() instead of in_softirq() ?
(would that allow us to drop the budget parameter?)
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH net] r8169:Remove unnecessary phy reset for pcie nic when setting link spped.
From: Francois Romieu @ 2016-03-09 21:44 UTC (permalink / raw)
To: Hau; +Cc: netdev@vger.kernel.org, nic_swsd, linux-kernel@vger.kernel.org
In-Reply-To: <80377ECBC5453840BA8C7155328B53770137C08D@RTITMBSV03.realtek.com.tw>
Hau <hau@realtek.com> :
[...]
> Unless pcie nic has bug, pcie nic does not need to reset phy to let phy link on.
>
> There is a counter for phy speed down. If phy is in link down state, this
> counter will start to count down. When it count to 0, phy will speed down.
> Reset phy will reset this counter and prevent phy from speed down.
Thanks for the clarification.
--
Ueimor
^ permalink raw reply
* Re: [net-next PATCH 2/7] mlx4: use napi_consume_skb API to get bulk free operations
From: Alexander Duyck @ 2016-03-09 21:43 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: David Miller, Netdev, eugenia, Alexei Starovoitov, Saeed Mahameed,
Or Gerlitz
In-Reply-To: <20160309223607.0ab4d61d@redhat.com>
On Wed, Mar 9, 2016 at 1:36 PM, Jesper Dangaard Brouer
<brouer@redhat.com> wrote:
> On Wed, 09 Mar 2016 16:03:20 -0500 (EST)
> David Miller <davem@davemloft.net> wrote:
>
>> From: Alexander Duyck <alexander.duyck@gmail.com>
>> Date: Wed, 9 Mar 2016 08:47:58 -0800
>>
>> > On Wed, Mar 9, 2016 at 3:00 AM, Jesper Dangaard Brouer
>> > <brouer@redhat.com> wrote:
>> >> Passing the budget down was Alex'es design. Axel any thoughts?
>> >
>> > I'd say just use dev_consume_skb_any in the bulk free instead of
>> > dev_consume_skb_irq. This is slow path, as you said, so it shouldn't
>> > come up often.
>>
>> Agreed.
>>
>> >> I do wonder how expensive this check is... as it goes into a code
>> >> hotpath, which is very unlikely. The good thing would be, that we
>> >> handle if buggy drivers call this function from a none softirq context
>> >> (as these bugs could be hard to catch).
>> >>
>> >> Can netpoll ever be called from softirq or with BH disabled? (It
>> >> disables IRQs, which would break calling kmem_cache_free_bulk).
>> >
>> > It is better for us to switch things out so that the napi_consume_skb
>> > is the fast path with dev_consume_skb_any as the slow. There are too
>> > many scenarios where we could be invoking something that makes use of
>> > this within the Tx path so it is probably easiest to just solve it
>> > that way so we don't have to deal with it again in the future.
>>
>> Indeed.
>
> So, if I understand you correctly, then we drop the budget parameter
> and check for in_softirq(), like:
>
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 7af7ec635d90..a3c61a9b65d2 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -796,14 +796,14 @@ void __kfree_skb_defer(struct sk_buff *skb)
> _kfree_skb_defer(skb);
> }
>
> -void napi_consume_skb(struct sk_buff *skb, int budget)
> +void napi_consume_skb(struct sk_buff *skb)
> {
> if (unlikely(!skb))
> return;
>
> - /* if budget is 0 assume netpoll w/ IRQs disabled */
> - if (unlikely(!budget)) {
> - dev_consume_skb_irq(skb);
> + /* Handle if not called from NAPI context, and netpoll invocation */
> + if (unlikely(!in_softirq())) {
> + dev_consume_skb_any(skb);
> return;
> }
>
No. We still need to have the budget value. What we do though is
have that feed into dev_consume_skb_any.
The problem with using in_softirq is that it will trigger if softirqs
are just disabled so there are more possible paths where it is
possible. For example the transmit path has bottom halves disabled so
I am pretty sure it might trigger this as well. We want this to only
execute when we are running from a NAPI polling routine with a
non-zero budget.
- Alex
^ permalink raw reply
* Re: [RFC PATCH net-next 1/2] net: bridge: add switchdev attr for port bridging
From: Ido Schimmel @ 2016-03-09 21:42 UTC (permalink / raw)
To: Vivien Didelot
Cc: netdev, linux-kernel, kernel, David S. Miller, Florian Fainelli,
Andrew Lunn, Scott Feldman, Jiri Pirko, nikolay, Elad Raz
In-Reply-To: <1457545368-20647-2-git-send-email-vivien.didelot@savoirfairelinux.com>
Hi Vivien,
Wed, Mar 09, 2016 at 07:42:47PM IST, vivien.didelot@savoirfairelinux.com wrote:
>Add a new SWITCHDEV_ATTR_ID_PORT_BRIDGE_IF switchdev attribute which is
>set before adding a port to a bridge and deleting a port from a bridge.
>
>The main purpose for this attribute is to provide switchdev users a
>simple and common way to retrieve bridging information, instead of
>implementing complex notifier blocks to listen to global netdev events.
>
>We can also imagine a switchdev user returning an error different from
>-EOPNOTSUPP in the prepare phase to prevent a port from being bridged.
I don't really understand the motivation for this change. We are already
doing all these stuff with the notifiers and it's pretty
straight-forward.
In fact, I believe using an existing mechanism instead of introducing
more switchdev hooks is more elegant. This RFC only deals with bridge,
but you'll have to do the same for team, bond and vlan devices. And
you'll probably place the hooks in the exact locations where the
notifiers are called from anyway.
>
>Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
>---
> include/net/switchdev.h | 2 ++
> net/bridge/br_if.c | 27 +++++++++++++++++++++++++++
> 2 files changed, 29 insertions(+)
>
>diff --git a/include/net/switchdev.h b/include/net/switchdev.h
>index d451122..65f8514 100644
>--- a/include/net/switchdev.h
>+++ b/include/net/switchdev.h
>@@ -46,6 +46,7 @@ enum switchdev_attr_id {
> SWITCHDEV_ATTR_ID_PORT_PARENT_ID,
> SWITCHDEV_ATTR_ID_PORT_STP_STATE,
> SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS,
>+ SWITCHDEV_ATTR_ID_PORT_BRIDGE_IF,
> SWITCHDEV_ATTR_ID_BRIDGE_AGEING_TIME,
> SWITCHDEV_ATTR_ID_BRIDGE_VLAN_FILTERING,
> };
>@@ -58,6 +59,7 @@ struct switchdev_attr {
> struct netdev_phys_item_id ppid; /* PORT_PARENT_ID */
> u8 stp_state; /* PORT_STP_STATE */
> unsigned long brport_flags; /* PORT_BRIDGE_FLAGS */
>+ bool join; /* PORT_BRIDGE_IF */
> u32 ageing_time; /* BRIDGE_AGEING_TIME */
> bool vlan_filtering; /* BRIDGE_VLAN_FILTERING */
> } u;
>diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
>index a73df33..105b9fd 100644
>--- a/net/bridge/br_if.c
>+++ b/net/bridge/br_if.c
>@@ -28,6 +28,24 @@
>
> #include "br_private.h"
>
>+static int switchdev_bridge_if(struct net_device *dev, struct net_bridge *br,
>+ bool join)
>+{
>+ struct switchdev_attr attr = {
>+ .orig_dev = br->dev,
This should be just 'dev', since you need to know for which stacked
device on top of the port this was called for. This also means you'll
have to call netdev_master_upper_dev_get() from within your driver if
you want to limit the number of VLAN filtering bridges (for example).
However, since this is called before bridge dev and dev itself are
linked, you'll get NULL.
>+ .id = SWITCHDEV_ATTR_ID_PORT_BRIDGE_IF,
>+ .flags = SWITCHDEV_F_SKIP_EOPNOTSUPP,
>+ .u.join = join,
>+ };
>+ int err;
>+
>+ err = switchdev_port_attr_set(dev, &attr);
>+ if (err && err != -EOPNOTSUPP)
>+ return err;
>+
>+ return 0;
>+}
>+
> /*
> * Determine initial path cost based on speed.
> * using recommendations from 802.1d standard
>@@ -297,6 +315,10 @@ static void del_nbp(struct net_bridge_port *p)
> br_netpoll_disable(p);
>
> call_rcu(&p->rcu, destroy_nbp_rcu);
>+
>+ if (switchdev_bridge_if(dev, br, false))
>+ br_warn(br, "error unbridging port %u(%s)\n",
>+ (unsigned int) p->port_no, dev->name);
> }
>
> /* Delete bridge device */
>@@ -347,6 +369,11 @@ static struct net_bridge_port *new_nbp(struct net_bridge *br,
> {
> int index;
> struct net_bridge_port *p;
>+ int err;
>+
>+ err = switchdev_bridge_if(dev, br, true);
If you look at br_add_if() - where new_nbp() is called from - then
you'll see that you aren't rollbacking this operation in case of error.
Same for subsequent errors in this function I believe.
>+ if (err)
>+ return ERR_PTR(err);
>
> index = find_portno(br);
> if (index < 0)
>--
>2.7.2
>
Maybe this is something we'll have to do in the future, but for now I
think we are OK with the notifiers. :)
Thanks Vivien!
^ permalink raw reply
* Re: [PATCH v2 net-next 00/13] kcm: Kernel Connection Multiplexor (KCM)
From: David Miller @ 2016-03-09 21:38 UTC (permalink / raw)
To: tom; +Cc: netdev, kernel-team
In-Reply-To: <1457388672-2600559-1-git-send-email-tom@herbertland.com>
From: Tom Herbert <tom@herbertland.com>
Date: Mon, 7 Mar 2016 14:10:59 -0800
> Kernel Connection Multiplexor (KCM) is a facility that provides a
> message based interface over TCP for generic application protocols.
...
I've decided to apply this as-is.
If there are any issues we can fix it with follow-on patches.
Thanks for all of the hard work Tom.
^ permalink raw reply
* Re: [net-next PATCH 2/7] mlx4: use napi_consume_skb API to get bulk free operations
From: Jesper Dangaard Brouer @ 2016-03-09 21:36 UTC (permalink / raw)
To: David Miller
Cc: alexander.duyck, netdev, eugenia, alexei.starovoitov, saeedm,
gerlitz.or, brouer
In-Reply-To: <20160309.160320.1535201013338177802.davem@davemloft.net>
On Wed, 09 Mar 2016 16:03:20 -0500 (EST)
David Miller <davem@davemloft.net> wrote:
> From: Alexander Duyck <alexander.duyck@gmail.com>
> Date: Wed, 9 Mar 2016 08:47:58 -0800
>
> > On Wed, Mar 9, 2016 at 3:00 AM, Jesper Dangaard Brouer
> > <brouer@redhat.com> wrote:
> >> Passing the budget down was Alex'es design. Axel any thoughts?
> >
> > I'd say just use dev_consume_skb_any in the bulk free instead of
> > dev_consume_skb_irq. This is slow path, as you said, so it shouldn't
> > come up often.
>
> Agreed.
>
> >> I do wonder how expensive this check is... as it goes into a code
> >> hotpath, which is very unlikely. The good thing would be, that we
> >> handle if buggy drivers call this function from a none softirq context
> >> (as these bugs could be hard to catch).
> >>
> >> Can netpoll ever be called from softirq or with BH disabled? (It
> >> disables IRQs, which would break calling kmem_cache_free_bulk).
> >
> > It is better for us to switch things out so that the napi_consume_skb
> > is the fast path with dev_consume_skb_any as the slow. There are too
> > many scenarios where we could be invoking something that makes use of
> > this within the Tx path so it is probably easiest to just solve it
> > that way so we don't have to deal with it again in the future.
>
> Indeed.
So, if I understand you correctly, then we drop the budget parameter
and check for in_softirq(), like:
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 7af7ec635d90..a3c61a9b65d2 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -796,14 +796,14 @@ void __kfree_skb_defer(struct sk_buff *skb)
_kfree_skb_defer(skb);
}
-void napi_consume_skb(struct sk_buff *skb, int budget)
+void napi_consume_skb(struct sk_buff *skb)
{
if (unlikely(!skb))
return;
- /* if budget is 0 assume netpoll w/ IRQs disabled */
- if (unlikely(!budget)) {
- dev_consume_skb_irq(skb);
+ /* Handle if not called from NAPI context, and netpoll invocation */
+ if (unlikely(!in_softirq())) {
+ dev_consume_skb_any(skb);
return;
}
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply related
* Re: [PATCH net-next] ovs: allow nl 'flow set' to use ufid without flow key
From: pravin shelar @ 2016-03-09 21:35 UTC (permalink / raw)
To: Samuel Gauthier; +Cc: ovs dev, Linux Kernel Network Developers, David S. Miller
In-Reply-To: <1457543157-5240-1-git-send-email-samuel.gauthier-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
On Wed, Mar 9, 2016 at 9:05 AM, Samuel Gauthier
<samuel.gauthier@6wind.com> wrote:
> When we want to change a flow using netlink, we have to identify it to
> be able to perform a lookup. Both the flow key and unique flow ID
> (ufid) are valid identifiers, but we always have to specify the flow
> key in the netlink message. When both attributes are there, the ufid
> is used.
>
> This commit allows to use the ufid without having to provide the flow
> key, as it is already done in the netlink 'flow get' and 'flow del'
> path.
>
> Signed-off-by: Samuel Gauthier <samuel.gauthier@6wind.com>
> ---
> net/openvswitch/datapath.c | 21 ++++++++++-----------
> 1 file changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
> index deadfdab1bc3..06f15143cf2a 100644
> --- a/net/openvswitch/datapath.c
> +++ b/net/openvswitch/datapath.c
> @@ -1100,21 +1100,20 @@ static int ovs_flow_cmd_set(struct sk_buff *skb, struct genl_info *info)
> struct sw_flow_match match;
> struct sw_flow_id sfid;
> u32 ufid_flags = ovs_nla_get_ufid_flags(a[OVS_FLOW_ATTR_UFID_FLAGS]);
> - int error;
> + int error = 0;
> bool log = !a[OVS_FLOW_ATTR_PROBE];
> bool ufid_present;
>
> - /* Extract key. */
> - error = -EINVAL;
> - if (!a[OVS_FLOW_ATTR_KEY]) {
> - OVS_NLERR(log, "Flow key attribute not present in set flow.");
> - goto error;
> - }
> -
> ufid_present = ovs_nla_get_ufid(&sfid, a[OVS_FLOW_ATTR_UFID], log);
> - ovs_match_init(&match, &key, &mask);
> - error = ovs_nla_get_match(net, &match, a[OVS_FLOW_ATTR_KEY],
> - a[OVS_FLOW_ATTR_MASK], log);
> + if (a[OVS_FLOW_ATTR_KEY]) {
> + ovs_match_init(&match, &key, NULL);
> + error = ovs_nla_get_match(net, &match, a[OVS_FLOW_ATTR_KEY],
> + NULL, log);
> + } else if (!ufid_present) {
> + OVS_NLERR(log,
> + "Flow set message rejected, Key attribute missing.");
> + error = -EINVAL;
> + }
Set command sets new action for given flow. The action validation
depends on the flow key and mask. so userspace needs to provide the
key and mask.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: [RFC] net: ipv4 -- Introduce ifa limit per net
From: Cyrill Gorcunov @ 2016-03-09 21:16 UTC (permalink / raw)
To: David Miller
Cc: alexei.starovoitov, eric.dumazet, netdev, solar, vvs, avagin,
xemul, vdavydov, khorenko, pablo, netfilter-devel
In-Reply-To: <20160309.161038.283281065293712589.davem@davemloft.net>
On Wed, Mar 09, 2016 at 04:10:38PM -0500, David Miller wrote:
> >
> > and here we call for NETDEV_DOWN, which then hits masq_device_event
> > and go further to conntrack code.
>
> Yes that's where the notifier comes from, which happens with or without
> my patch.
Thanks for explanation, Dave! I'll continue on this task tomorrow
tryin to implement optimization you proposed.
^ permalink raw reply
* Re: [RFC] net: ipv4 -- Introduce ifa limit per net
From: David Miller @ 2016-03-09 21:10 UTC (permalink / raw)
To: gorcunov
Cc: alexei.starovoitov, eric.dumazet, netdev, solar, vvs, avagin,
xemul, vdavydov, khorenko, pablo, netfilter-devel
In-Reply-To: <20160309205746.GQ2207@uranus.lan>
From: Cyrill Gorcunov <gorcunov@gmail.com>
Date: Wed, 9 Mar 2016 23:57:47 +0300
> Aha! So in your patch __inet_del_ifa bypass first blocking_notifier_call_chain
>
> __inet_del_ifa
> ...
> if (in_dev->dead)
> goto no_promotions;
>
> // First call to NETDEV_DOWN
> ...
> no_promotions:
> rtmsg_ifa(RTM_DELADDR, ifa1, nlh, portid);
> blocking_notifier_call_chain(&inetaddr_chain, NETDEV_DOWN, ifa1);
>
> and here we call for NETDEV_DOWN, which then hits masq_device_event
> and go further to conntrack code.
Yes that's where the notifier comes from, which happens with or without
my patch.
^ permalink raw reply
* Re: [net-next PATCH 2/7] mlx4: use napi_consume_skb API to get bulk free operations
From: David Miller @ 2016-03-09 21:03 UTC (permalink / raw)
To: alexander.duyck
Cc: brouer, netdev, eugenia, alexei.starovoitov, saeedm, gerlitz.or
In-Reply-To: <CAKgT0UeiAaMdGOzqFcC2iWRvrFC1MUcFM6czU=Kd+Et=5MGp0w@mail.gmail.com>
From: Alexander Duyck <alexander.duyck@gmail.com>
Date: Wed, 9 Mar 2016 08:47:58 -0800
> On Wed, Mar 9, 2016 at 3:00 AM, Jesper Dangaard Brouer
> <brouer@redhat.com> wrote:
>> Passing the budget down was Alex'es design. Axel any thoughts?
>
> I'd say just use dev_consume_skb_any in the bulk free instead of
> dev_consume_skb_irq. This is slow path, as you said, so it shouldn't
> come up often.
Agreed.
>> I do wonder how expensive this check is... as it goes into a code
>> hotpath, which is very unlikely. The good thing would be, that we
>> handle if buggy drivers call this function from a none softirq context
>> (as these bugs could be hard to catch).
>>
>> Can netpoll ever be called from softirq or with BH disabled? (It
>> disables IRQs, which would break calling kmem_cache_free_bulk).
>
> It is better for us to switch things out so that the napi_consume_skb
> is the fast path with dev_consume_skb_any as the slow. There are too
> many scenarios where we could be invoking something that makes use of
> this within the Tx path so it is probably easiest to just solve it
> that way so we don't have to deal with it again in the future.
Indeed.
^ permalink raw reply
* Re: [net-next PATCH 3/4] vxlan: Enforce IP ID verification on outer headers
From: David Miller @ 2016-03-09 21:02 UTC (permalink / raw)
To: jesse; +Cc: aduyck, gerlitz.or, netdev
In-Reply-To: <CAEh+42goYHorJiP2ShhMj6CXCfPyn1r+obb0YsKXLeZFNW2PLw@mail.gmail.com>
From: Jesse Gross <jesse@kernel.org>
Date: Mon, 7 Mar 2016 15:42:59 -0800
> On Mon, Mar 7, 2016 at 3:06 PM, Alex Duyck <aduyck@mirantis.com> wrote:
>> On Mon, Mar 7, 2016 at 11:09 AM, David Miller <davem@davemloft.net> wrote:
>>> From: Or Gerlitz <gerlitz.or@gmail.com>
>>> Date: Mon, 7 Mar 2016 20:05:20 +0200
>>>
>>>> On Mon, Mar 7, 2016 at 7:22 PM, Alexander Duyck <aduyck@mirantis.com> wrote:
>>>>> This change enforces the IP ID verification on outer headers. As a result
>>>>> if the DF flag is not set on the outer header we will force the flow to be
>>>>> flushed in the event that the IP ID is out of sequence with the existing
>>>>> flow.
>>>>
>>>> Can you please state the precise requirement for aggregation w.r.t IP
>>>> IDs here? and point to where/how this is enforced, e.g for
>>>> non-tunneled TCP GRO-ing?
>>>
>>> I also didn't see a nice "PATCH 0/4" posting explaining this series and
>>> I'd really like to see that.
>>
>> Sorry about that. I forgot to add the cover page when I sent this.
>>
>> The enforcement is coming from the IP and TCP layers. If you take a
>> look in inet_gro_receive we have the NAPI_GRO_CB(p)->flush_id value
>> being populated based on the difference between the expected ID and
>> the received one. So for IPv4 we overwrite it, and for IPv6 we set it
>> to 0. The only consumer currently using it is TCP in tcp_gro_receive.
>> The problem is with tunnels we lose the data for the outer when the
>> inner overwrites it, as a result we can put whatever we want currently
>> in the outer IP ID and it will be accepted.
>>
>> The patch set is based off of a conversation several of us had on the
>> list about doing TSO for tunnels and the fact that the IP IDs for the
>> outer header have to advance. It makes it easier for me to validate
>> that I am doing things properly if GRO doesn't destroy the IP ID data
>> for the outer headers.
>
> In net/ipv4/af_inet.c:inet_gro_receive() there is the following
> comment above where NAPI_GRO_CB(p)->flush_id is set:
>
> /* Save the IP ID check to be included later when we get to
> * the transport layer so only the inner most IP ID is checked.
> * This is because some GSO/TSO implementations do not
> * correctly increment the IP ID for the outer hdrs.
> */
>
> There was a long discussion about this a couple years ago and the
> conclusion was that it is the inner IP ID is really the important one
> in the case of encapsulation. Obviously, things like TCP/IP header
> compression don't apply to the outer encapsulation header.
That's how I remember the conversation going as wel...
^ permalink raw reply
* Re: [RFC] net: ipv4 -- Introduce ifa limit per net
From: Cyrill Gorcunov @ 2016-03-09 20:57 UTC (permalink / raw)
To: David Miller
Cc: alexei.starovoitov, eric.dumazet, netdev, solar, vvs, avagin,
xemul, vdavydov, khorenko, pablo, netfilter-devel
In-Reply-To: <20160309.154725.1921352291794389965.davem@davemloft.net>
On Wed, Mar 09, 2016 at 03:47:25PM -0500, David Miller wrote:
> From: Cyrill Gorcunov <gorcunov@gmail.com>
> Date: Wed, 9 Mar 2016 23:41:58 +0300
>
> > On Wed, Mar 09, 2016 at 03:27:30PM -0500, David Miller wrote:
> >> >
> >> > Yes. I can drop it off for a while and run tests without it,
> >> > then turn it back and try again. Would you like to see such
> >> > numbers?
> >>
> >> That would be very helpful, yes.
> >
> > Just sent out. Take a look please. Indeed it sits inside get_next_corpse
> > a lot. And now I think I've to figure out where we can optimize it.
> > Continue tomorrow.
>
> The problem is that the masquerading code flushes the entire conntrack
> table once for _every_ address removed.
>
> The code path is:
>
> masq_device_event()
> if (event == NETDEV_DOWN) {
> /* Device was downed. Search entire table for
> * conntracks which were associated with that device,
> * and forget them.
> */
> NF_CT_ASSERT(dev->ifindex != 0);
>
> nf_ct_iterate_cleanup(net, device_cmp,
> (void *)(long)dev->ifindex, 0, 0);
>
> So if you have a million IP addresses, this flush happens a million times
> on inetdev destroy.
>
> Part of the problem is that we emit NETDEV_DOWN inetdev notifiers per
> address removed, instead of once per inetdev destroy.
>
> Maybe if we put some boolean state into the inetdev, we could make sure
> we did this flush only once time while inetdev->dead = 1.
Aha! So in your patch __inet_del_ifa bypass first blocking_notifier_call_chain
__inet_del_ifa
...
if (in_dev->dead)
goto no_promotions;
// First call to NETDEV_DOWN
...
no_promotions:
rtmsg_ifa(RTM_DELADDR, ifa1, nlh, portid);
blocking_notifier_call_chain(&inetaddr_chain, NETDEV_DOWN, ifa1);
and here we call for NETDEV_DOWN, which then hits masq_device_event
and go further to conntrack code.
^ permalink raw reply
* Re: [PATCH net 0/3] validate variable length ll headers
From: David Miller @ 2016-03-09 20:54 UTC (permalink / raw)
To: willemdebruijn.kernel
Cc: netdev, alan, hessu, martin.blumenstingl, linux-hams, willemb
In-Reply-To: <1457124257-31486-1-git-send-email-willemdebruijn.kernel@gmail.com>
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: Fri, 4 Mar 2016 15:44:14 -0500
> From: Willem de Bruijn <willemb@google.com>
>
> Allow device-specific validation of link layer headers. Existing
> checks drop all packets shorter than hard_header_len. For variable
> length protocols, such packets can be valid.
>
> patch 1 adds header_ops.validate and dev_validate_header
> patch 2 replaces ll_header_truncated with dev_validate_header
> patch 3 implements the protocol specific callback for AX25
>
> Tested with a temporary eth_header_validate function. The AX25
> code is compile-tested only at this point.
I'm not going to be able to send another pull request to Linus
before -final, so please respin this against net-next and I'll
queue it up for -stable.
You can add the missing Fixes: tags as well when you do this.
Thanks.
^ permalink raw reply
* Re: [RFC] net: ipv4 -- Introduce ifa limit per net
From: David Miller @ 2016-03-09 20:47 UTC (permalink / raw)
To: gorcunov
Cc: alexei.starovoitov, eric.dumazet, netdev, solar, vvs, avagin,
xemul, vdavydov, khorenko, pablo, netfilter-devel
In-Reply-To: <20160309204158.GO2207@uranus.lan>
From: Cyrill Gorcunov <gorcunov@gmail.com>
Date: Wed, 9 Mar 2016 23:41:58 +0300
> On Wed, Mar 09, 2016 at 03:27:30PM -0500, David Miller wrote:
>> >
>> > Yes. I can drop it off for a while and run tests without it,
>> > then turn it back and try again. Would you like to see such
>> > numbers?
>>
>> That would be very helpful, yes.
>
> Just sent out. Take a look please. Indeed it sits inside get_next_corpse
> a lot. And now I think I've to figure out where we can optimize it.
> Continue tomorrow.
The problem is that the masquerading code flushes the entire conntrack
table once for _every_ address removed.
The code path is:
masq_device_event()
if (event == NETDEV_DOWN) {
/* Device was downed. Search entire table for
* conntracks which were associated with that device,
* and forget them.
*/
NF_CT_ASSERT(dev->ifindex != 0);
nf_ct_iterate_cleanup(net, device_cmp,
(void *)(long)dev->ifindex, 0, 0);
So if you have a million IP addresses, this flush happens a million times
on inetdev destroy.
Part of the problem is that we emit NETDEV_DOWN inetdev notifiers per
address removed, instead of once per inetdev destroy.
Maybe if we put some boolean state into the inetdev, we could make sure
we did this flush only once time while inetdev->dead = 1.
^ permalink raw reply
* Kreditfinanzierung . Kontaktieren Sie uns für weitere Informationen.
From: EuroFinance Group @ 2016-03-09 20:33 UTC (permalink / raw)
Guten Tag
Wir möchten Sie informieren, dass wir GeschäftDarlehen, Projektfinanzierung, Immobilienfinanzierung bei 1% Jahreszinssatz bieten. Für weitere Informationen kontaktieren Sie uns über folgende e-Mail: eurofinance19@gmail.com. Senden Sie Ihren Darlehensantrag einschließlich Ihren vollständigen Namen, Darlehensbetrag Betrag erforderlich, Darlehenslaufzeit und Ihre Adresse/Telefonnummer. Wir senden Ihnen die Kreditkonditionen und Rückzahlung nach Erhalt Ihrer KreditAnfrage Informationen. Ich freue mich auf Ihre Antwort.
Senden Sie Ihre Kreditanfrage an unser Büro E-Mail: eurofinance19@gmail.com
Vielen Dank.
Grüße,
Josef Pani
^ permalink raw reply
* Re: [RFC] net: ipv4 -- Introduce ifa limit per net
From: Cyrill Gorcunov @ 2016-03-09 20:41 UTC (permalink / raw)
To: David Miller
Cc: alexei.starovoitov, eric.dumazet, netdev, solar, vvs, avagin,
xemul, vdavydov, khorenko
In-Reply-To: <20160309.152730.691838022304871697.davem@davemloft.net>
On Wed, Mar 09, 2016 at 03:27:30PM -0500, David Miller wrote:
> >
> > Yes. I can drop it off for a while and run tests without it,
> > then turn it back and try again. Would you like to see such
> > numbers?
>
> That would be very helpful, yes.
Just sent out. Take a look please. Indeed it sits inside get_next_corpse
a lot. And now I think I've to figure out where we can optimize it.
Continue tomorrow.
^ permalink raw reply
* Re: [PATCH] inet: set `error' value not under lock_sock().
From: David Miller @ 2016-03-09 20:37 UTC (permalink / raw)
To: wjeong, weongyo.linux; +Cc: netdev
In-Reply-To: <20160309182217.GA9708@jwg>
From: Weongyo Jeong <weongyo.linux@gmail.com>
Date: Wed, 9 Mar 2016 10:22:21 -0800
> A trivial patch to set `error' variable while not holding
> lock_sock().
>
> Signed-off-by: Weongyo Jeong <weongyo.linux@gmail.com>
Deferring the assignment means gcc doesn't have to potentially put it
on the stack across the lock_sock() call.
You're making the code worse not better, the assignment into a local
variable is not an expensive operation.
I'm not applying this change, sorry.
^ permalink raw reply
* Re: [RFC] net: ipv4 -- Introduce ifa limit per net
From: David Miller @ 2016-03-09 20:27 UTC (permalink / raw)
To: gorcunov
Cc: alexei.starovoitov, eric.dumazet, netdev, solar, vvs, avagin,
xemul, vdavydov, khorenko
In-Reply-To: <20160309175307.GM2207@uranus.lan>
From: Cyrill Gorcunov <gorcunov@gmail.com>
Date: Wed, 9 Mar 2016 20:53:07 +0300
> On Wed, Mar 09, 2016 at 12:24:00PM -0500, David Miller wrote:
> ...
>> We asked you for numbers without a lot of features enabled, it'll
>> help us diagnose which subsystem still causes a lot of overhead
>> much more clearly.
>>
>> So please do so.
>
> Sure. Gimme some time and I'll back with numbers.
>
>> Although it's already pretty clear that netfilter conntrack
>> cleanup is insanely expensive.
>
> Yes. I can drop it off for a while and run tests without it,
> then turn it back and try again. Would you like to see such
> numbers?
That would be very helpful, yes.
^ permalink raw reply
* Re: [PATCH 0/3] net: macb: Fix coding style issues
From: David Miller @ 2016-03-09 20:26 UTC (permalink / raw)
To: michal.simek
Cc: nicolas.ferre, moritz.fischer, cyrille.pitchen, punnaia, netdev,
linux-kernel
In-Reply-To: <56E05D5D.80604@xilinx.com>
From: Michal Simek <michal.simek@xilinx.com>
Date: Wed, 9 Mar 2016 18:29:01 +0100
> On 9.3.2016 18:22, David Miller wrote:
>> From: Michal Simek <michal.simek@xilinx.com>
>> Date: Wed, 9 Mar 2016 17:29:39 +0100
>>
>>> On 7.3.2016 18:13, Nicolas Ferre wrote:
>>>> Le 07/03/2016 17:17, Moritz Fischer a écrit :
>>>>> Hi Nicolas,
>>>>>
>>>>> this series deals with most of the checkpatch warnings
>>>>> generated for macb. There are two BUG_ON()'s that I didn't touch, yet,
>>>>> that were suggested by checkpatch, that I can address in a follow up
>>>>> commit if needed.
>>>>> Let me know if you want me to split the fixes differently or squash
>>>>> them into one commit.
>>>>
>>>> Hi,
>>>>
>>>> I'm not usually fond of this type of patches, but I must admit that this
>>>> series corrects some style issues.
>>>>
>>>> So, I would like more feedback from Michal and Cyrille as these changes
>>>> may delay some of the not-merged-yet features or more important
>>>> work-in-progress on their side.
>>>>
>>>> On the other hand, if we all think it's a calm period for this macb
>>>> driver, we may find interesting to merge some "cleanup and style"
>>>> enhancements.
>>>
>>> Not a problem with merging cleanups in general. We have several out of
>>> tree patches but doesn't make sense to to wait.
>>> I wasn't in cc for the series but I don't like this change to be the
>>> part of cleanup series.
>>>
>>> mac = of_get_mac_address(np);
>>> if (mac)
>>> - memcpy(bp->dev->dev_addr, mac, ETH_ALEN);
>>> + ether_addr_copy(bp->dev->dev_addr, mac);
>>
>> Why? This is what we tell people to use.
>
> I would expect this as separate patch not the part of one huge cleanup
> patch which does just comment and space cleanups.
That is true.
^ permalink raw reply
* Re: [RFC PATCH net-next 2/2] net: dsa: support SWITCHDEV_ATTR_ID_PORT_BRIDGE_IF
From: Andrew Lunn @ 2016-03-09 20:07 UTC (permalink / raw)
To: Vivien Didelot
Cc: netdev, linux-kernel, kernel, David S. Miller, Florian Fainelli,
Scott Feldman, Jiri Pirko, Ido Schimmel, nikolay, Elad Raz
In-Reply-To: <87h9gfo3be.fsf@ketchup.mtl.sfl>
On Wed, Mar 09, 2016 at 02:32:05PM -0500, Vivien Didelot wrote:
> Hi Andrew,
>
> Andrew Lunn <andrew@lunn.ch> writes:
>
> >> -static bool dsa_slave_dev_check(struct net_device *dev)
> >> -{
> >> - return dev->netdev_ops == &dsa_slave_netdev_ops;
> >> -}
> >
> > Where is the equivalent of this happening? Where do we check that the
> > interface added to the bridge is part of the switch?
>
> Why should we check that? In this RFC, br_if.c tries to set the new
> attribute to the net_device, when creating and deleting the net bridge
> port. If it supports attr_set and this attribute, then we're good. Or am
> I missing something?
One of us is missing something...
What happens if i have two dsa clusters? We probably want to limit the
object to only being passed to the DSA cluster which contains the
port, or once we receive the object, we verify it belongs to the
cluster processing it.
What happens with a team/bind interface is added to the bridge. In the
future we need to know about this, so we can add the trunk in Marvells
terms to the bridge.
> > How about team/bonding? We are not ready to implement it yet with the
> > Marvell devices, but at some point we probably will. Won't we need the
> > events then? We need to know when a switch port has been added to a
> > team?
> >
> > Or do you think a switchdev object will be added for this case?
> > Mellanox already have the ability to add switch interfaces to a team,
> > and then add the team to a bridge. So we need to ensure your solution
> > works for such stacked systems.
>
> Indeed these features can be propagated through new switchdev attributes
> or objects.
>
> I think it'd be preferable to factorize the switch related operations
> into the switchdev API, instead of having every single switchdev user
> implement its custom (but similar) listeners and checks for global
> netdev events. What do you think?
Centralizing the code would be good. But DSA is way behind what
Mellanox can do, so you need to look at how your changes fit into
their driver.
During a netdev 1.1 BOF there was a conversation about the stack of
interfaces, teams/bonds, bridges, etc. If the video is available, you
might find it interesting.
Andrew
^ permalink raw reply
* pull-request: wireless-drivers-next 2016-03-09
From: Kalle Valo @ 2016-03-09 20:06 UTC (permalink / raw)
To: David Miller
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
Hi Dave,
here's a pull request for 4.6. I'm planning to send one more but I'm not
sure if it will make it in time, we'll see.
Here notable changes are refactoring in bcma to create a common flash
driver, brcmfmac platform data improvements in include/linux and
beginning of AHB bus support for ath10k along with device tree binding
update. More info in the signed tag below.
Oh, and I just noticed that weirdly my name appeared in author field on
one of Janusz' ath9k patches. But I didn't consider this bad enough to
rebase everything so I let it be. Sorry Janusz :)
commit b9a9693fd9aea43f50b107dfc8cbaea317f95a79
Author: Kalle Valo <Janusz.Dziedzic-++hxYGjEMp0AvxtiuMwx3w@public.gmane.org>
Date: Fri Nov 27 09:37:14 2015 +0100
ath9k: request NOA update when chanctx active
Please let me know if you have any problems.
Kalle
The following changes since commit 00a1f0a93dea3cf1c141df79bfd06e7c9ee54162:
Merge branch 'reset_mac_header' (2016-03-04 22:45:14 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git tags/wireless-drivers-next-for-davem-2016-03-09
for you to fetch changes up to 836856e3bd61d0644e5178a2c1b51d90459e2788:
wireless: cw1200: use __maybe_unused to hide pm functions_ (2016-03-08 12:32:52 +0200)
----------------------------------------------------------------
wireless-drivers patches for 4.6
Major changes:
ath10k
* dt: add bindings for ipq4019 wifi block
* start adding support for qca4019 chip
ath9k
* add device ID for Toshiba WLM-20U2/GN-1080
* allow more than one interface on DFS channels
bcma
* move flash detection code to ChipCommon core driver
brcmfmac
* IPv6 Neighbor discovery offload
* driver settings that can be populated from different sources
* country code setting in firmware
* length checks to validate firmware events
* new way to determine device memory size needed for BCM4366
* various offloads during Wake on Wireless LAN (WoWLAN)
* full Management Frame Protection (MFP) support
iwlwifi
* add support for thermal device / cooling device
* improvements in scheduled scan without profiles
* new firmware support (-21.ucode)
* add MSIX support for 9000 devices
* enable MU-MIMO and take care of firmware restart
* add support for large SKBs in mvm to reach A-MSDU
* add support for filtering frames from a BA session
* start implementing the new Rx path for 9000 devices
* enable the new Radio Resource Management (RRM) nl80211 feature flag
* add a new module paramater to disable VHT
* build infrastructure for Dynamic Queue Allocation
----------------------------------------------------------------
Alexander Tsoy (1):
ath9k_htc: add device ID for Toshiba WLM-20U2/GN-1080
Alexey Khoroshilov (1):
at76c50x-usb: avoid double usb_put_dev() after downloading internal firmware in at76_probe()
Amitkumar Karwar (1):
mwifiex: fix corner case association failure
Amitoj Kaur Chawla (1):
mwifiex: Use to_delayed_work()
Andrei Otcheretianski (1):
iwlwifi: add disable_11ac module param
Anilkumar Kolli (1):
ath10k: reduce number of peers to support peer stats feature
Anthony Wong (1):
rt2x00: add new rt2800usb device Buffalo WLI-UC-G450
Anton Protopopov (1):
ath10k: fix erroneous return value
Arend van Spriel (1):
brcmfmac: change function name for brcmf_cfg80211_wait_vif_event_timeout()
Arnd Bergmann (2):
ath9k: reduce stack usage in ar9003_aic_cal_post_process
wireless: cw1200: use __maybe_unused to hide pm functions_
Ashok Raj Nagarajan (2):
ath10k: fix pktlog in QCA99X0
ath10k: add hw_rev to trace events to support pktlog
Avri Altman (2):
iwlwifi: mvm: forbid U-APSD for P2P Client if the firmware doesn't support it
iwlwifi: mvm: Send power command on BSS_CHANGED_BEACON_INFO if needed
Beni Lev (1):
iwlwifi: mvm: Set global RRM capability
Bruno Randolf (3):
rtl8xxxu: Enable monitor mode by handling filters
rtl8xxxu: Document REG_RXFLTMAP registers
rtl8xxxu: Enable data frame reception in rtl8xxxu_start
Chaya Rachel Ivgi (4):
iwlwifi: mvm: add CT-KILL notification
iwlwifi: mvm: add registration to thermal zone
iwlwifi: mvm: add registration to cooling device
iwlwifi: mvm: update ucode status before stopping device
Christian Lamparter (1):
carl9170: import 1.9.9 firmware headers
Colin Ian King (2):
rtlwifi: pass struct rtl_stats by reference as it is more efficient
mt7601u: do not free dma_buf when ivp allocation fails
Dan Carpenter (1):
mwifiex: fix an indenting mistake
Emmanuel Grumbach (15):
Merge tag 'mac80211-next-for-davem-2016-02-26' into next2
Merge tag 'iwlwifi-for-kalle-2016-02-15' into HEAD
iwlwifi: mvm: bump firmware API to 21
iwlwifi: pcie: aggregate Flow Handler configuration writes
iwlwifi: pcie: fix identation in trans.c
iwlwifi: mvm: send large SKBs to the transport
iwlwifi: mvm: add Tx A-MSDU inside A-MPDU
iwlwifi: mvm: allow to limit the A-MSDU from debugfs
iwlwifi: mvm: don't enable A-MSDU when the rates are too low
iwlwifi: mvm: don't send an A-MSDU that is larger than the TXF
iwlwifi: pcie: prevent skbs shadowing in iwl_trans_pcie_reclaim
iwlwifi: mvm: remove unused field in iwl_mvm_tid_data
iwlwifi: mvm: various trivial cleanups
iwlwifi: mvm: kill iwl_mvm_enable_agg_txq
Merge branch 'fixes' into next
Eyal Shapira (1):
iwlwifi: mvm: rs: fix a theoretical access to uninitialized array elements
Felix Fietkau (2):
ath9k_hw: add low power tx gain table for AR953x
ath9k: do not limit the number of DFS channel interfaces to 1
Franky Lin (3):
brcmfmac: check for wowl support before enumerating feature flag
brcmfmac: add neighbor discovery offload ip address table configuration
brcmfmac: check return for ARP ip setting iovar
Geert Uytterhoeven (1):
ath9k: Drop useless const on chanctx_event_delta() return type
Golan Ben-Ami (1):
iwlwifi: support ucode with d0 unified image - regular and usniffer
Haim Dreyfuss (1):
iwlwifi: pcie: Add new configuration to enable MSIX
Hamad Kadmany (1):
wil6210: TX vring optimization
Hante Meuleman (17):
brcmfmac: Increase nr of supported flowrings.
brcmfmac: Limit memory allocs to <64K
brcmfmac: Configure country code using device specific settings
brcmfmac: Add length checks on firmware events
brcmfmac: use device memsize config from fw if defined
brcmfmac: use bar1 window size as provided by pci subsystem
brcmfmac: add support for the PCIE 4366c0 chip
brcmfmac: remove pcie gen1 support
brcmfmac: increase timeout for tx eapol
brcmfmac: move module init and exit to common
brcmfmac: add wowl gtk rekeying offload support
brcmfmac: move platform data retrieval code to common
brcmfmac: keep ARP and ND offload enabled during WOWL
brcmfmac: switch to new platform data
brcmfmac: merge platform data and module paramaters
brcmfmac: integrate add_keyext in add_key
brcmfmac: add 802.11w management frame protection support
Jakub Sitnicki (1):
rtl8xxxu: Use REG_EFUSE_TEST register only on multifunctional devices
Jes Sorensen (22):
rtl8xxxu: Minor cleanup to rtl8xxxu_download_firmware()
rtl8xxxu: rtl8xxxu_download_firmware(): Cosmetic cleanups
rtl8xxxu: If fw running in RAM, reset the 8051 before trying to download a new one
rtl8xxxu: Add RQPN_[NE]PQ_SHIFT values
rtl8xxxu: Define SYS_CFG_SW_OFFLOAD_EN
rtl8xxxu: Add REG_TX_REPORT_* defines
rtl8xxxu: Add more RCR bits
rtl8xxxu: Implement rtl8xxxu_reset_8051()
rtl8xxxu: Add definitions for antenna selection registers for 8723BU
rtl8xxxu: Add mbox extension register definitions for 8723B
rtl8xxxu: Add REG_OFDM0_RX_D_SYNC_PATH definitions
rtl8xxxu: Remove unused clutter for handling recursive calls to rtl8xxxu_init_device()
rtl8xxxu: Fix cosmetics to quiet down checkpatch police
rtl8xxxu: Remove duplicate USB ID
rtl8xxxu: Fix 80 character per line issue
rtl8xxxu: rtl8xxxu_set_linktype(): Be consistent aboutregister size REG_MSR
rtl8xxxu: Set correct bit to reset MCU IO wrapper
rtl8xxxu: Remove unused mgmt variable from rtl8xxxu_rx_complete()
rtl8xxxu: Remove unused len/cnt variables from rtl8xxxu_rx_complete()
rtl8xxxu: Do not mask RF registers to 6 bits
rtl8xxxu: Make device_init kludge 8723au only
rtl8xxxu: Add missing bit define for REG_APS_FSMCO
Kalle Valo (4):
ath9k: request NOA update when chanctx active
Merge ath-next from ath.git
Merge 'net-next/master'
Merge tag 'iwlwifi-next-for-kalle-2016-03-02' of https://git.kernel.org/.../iwlwifi/iwlwifi-next
Larry Finger (7):
rtlwifi: Prepare for reworking 5G channels
rtlwifi: rtl8192de: Convert driver to use common 5G channels
rtlwifi: rtl8192ee: Convert driver to use new 5G channel tables
rtlwifi: rtl8821ae: Convert driver to use common 5G channel table
rtlwifi: rtl8821ae: Silence useless log output
rtlwifi: Change long delays to sleeps
rtlwifi: Fix size of wireless mode variable
Lars-Peter Clausen (2):
b43: Remove unnecessary synchronize_irq() before free_irq()
rtlwifi: Remove unnecessary synchronize_irq() before free_irq()
Liad Kaufman (2):
iwlwifi: mvm: disable DQA support
iwlwifi: mvm: support sw queue start/stop from mvm
Lior David (2):
wil6210: fix privacy flag calculation in change_beacon
wil6210: use extra IEs from probe response
Luca Coelho (4):
iwlwifi: mvm: handle pass all scan reporting
iwlwifi: pcie: add pm_prepare and pm_complete ops
iwlwifi: mvm: only release the trans ref if d0i3 is supported in fw
iwlwifi: mvm: take the transport ref back when leaving
Matti Gottlieb (1):
iwlwifi: mvm: Disable beacon storing in D3 when WOWLAN configured
Maya Erez (5):
wil6210: handle tx completions only if vring tx data is enabled
wil6210: find TX vring only if vring_tx_data is enabled
wil6210: handle multiple connect/disconnect events
wil6210: prevent access to vring_tx_data lock during its init
wil6210: protect synchronous wmi commands handling
Miaoqing Pan (7):
ath9k: avoid ANI restart if no trigger
ath9k: clean up ANI per-channel pointer checking
ath9k: do not reset while BB panic(0x4000409) on ar9561
ath9k: fix inconsistent use of tab and space in indentation
ath9k: fix data bus error on ar9300 and ar9580
ath9k: make NF load complete quickly and reliably
ath9k: clear bb filter calibration power threshold
Michal Kazior (6):
ath10k: prevent txrx running for too long
ath10k: rename some HTT events
ath10k: add new htt definitions
ath10k: add new FW_FEATURE_PEER_FLOW_CONTROL
ath10k: clean up cont frag desc init code
ath10k: implement basic support for new tx path firmware
Mohammed Shafi Shajakhan (10):
ath10k: add support for parsing per STA rx_duration for 10.2.4
ath10k: fix naming Peer stats rssi_changed field in 10.2.4
ath10k: cleanup setting pdev paramaters
ath10k: rename few function names of firmware stats
ath10k: provision to support periodic peer stats update
ath10k: enable periodic peer stats update
ath10k: add debugfs support for Per STA total rx duration
ath10k: fix updating peer stats rx duration
ath10k: fix pointless update of peer stats list
ath10k: fix sanity check on enabling btcoex via debugfs
One Thousand Gnomes (1):
rt2x00: unterminated strlen of user data
Peter Oh (4):
ath10k: rename Mesh related service names
ath10k: update 10.4 WMI service map
ath10k: use vif->type and vif->p2p for P2P_GO check
ath10k: add abstraction layer for vdev subtype
Rafał Miłecki (3):
bcma: drop unneeded fields from bcma_pflash struct
bcma: move parallel flash support to separated file
bcma: move flash detection code to ChipCommon core driver
Raja Mani (15):
dt: bindings: add bindings for ipq4019 wifi block
ath10k: make some of ath10k_pci_* func reusable
ath10k: make ath10k_pci_read32/write32() ops more generic
ath10k: pull reusable code from pci probe and remove for ahb
ath10k: add basic skeleton to support ahb
ath10k: include qca4019 register map table
ath10k: add helper functions in ahb.c for reg rd/wr
ath10k: add clock ctrl related functions in ahb
ath10k: add reset ctrl related functions in ahb
ath10k: add chip and bus halt logic in ahb
ath10k: include irq related functions in ahb
ath10k: add resource init and deinit in ahb
ath10k: expose hif ops for ahb
ath10k: add qca4019 hw params
ath10k: populate qca4019 fw specific wmi init params
Rajkumar Manoharan (2):
ath10k: reduce rx_lock contention for htt rx indication
ath10k: process htt rx indication as batch mode
Sara Sharon (13):
iwlwifi: mvm: set the correct descriptor size for tracing
iwlwifi: mvm: fix RSS key sizing
iwlwifi: mvm: enable VHT MU-MIMO for supported hardware
iwlwifi: mvm: update firmware of VHT MU-MIMO groups status on restart
iwlwifi: support tracing wide commands
iwlwifi: mvm: update rx_status with mactime flag
iwlwifi: mvm: support filtered frames notification
iwlwifi: pcie: configure more RFH settings
iwlwifi: mvm: add duplicate packet detection per rx queue
iwlwifi: mvm: add RSS queues notification infrastructure
iwlwifi: mvm: support VHT MU-MIMO notification
iwlwifi: mvm: take care of padded packets
iwlwifi: pcie: detect and workaround invalid write ptr behavior
Sudip Mukherjee (1):
ath10k: remove impossible code
Tobias Klauser (2):
rtl8xxxu: Fix typo in Kconfig help text
rtl8xxxu: Check return value of kmemdup()
Ujjal Roy (3):
mwifiex: Fixed incorrect indentation issue
mwifiex: Removed extra spaces before commas
mwifiex: Added missing spaces around brackets
Vladimir Kondratiev (1):
wil6210: wait for disconnect completion
Xinming Hu (3):
mwifiex: add delay when tdls confirm frame is queued
mwifiex: add sdio multiport aggregation debug information
mwifiex: do not set multiport flag for tx/rx single packet
Yanbo Li (1):
ath10k: remove the p2p notice of absence info from 10.2.4 FW beacon info
.../bindings/net/wireless/qcom,ath10k.txt | 89 +-
drivers/bcma/Kconfig | 5 +
drivers/bcma/Makefile | 1 +
drivers/bcma/bcma_private.h | 18 +-
drivers/bcma/driver_chipcommon.c | 30 +
drivers/bcma/driver_chipcommon_pflash.c | 49 +
drivers/bcma/driver_mips.c | 63 +-
drivers/bcma/main.c | 2 +-
drivers/net/wireless/ath/ath10k/Kconfig | 6 +
drivers/net/wireless/ath/ath10k/Makefile | 2 +
drivers/net/wireless/ath/ath10k/ahb.c | 933 ++++++++++++++++++++
drivers/net/wireless/ath/ath10k/ahb.h | 87 ++
drivers/net/wireless/ath/ath10k/core.c | 48 +-
drivers/net/wireless/ath/ath10k/core.h | 20 +
drivers/net/wireless/ath/ath10k/debug.c | 46 +-
drivers/net/wireless/ath/ath10k/debug.h | 7 +
drivers/net/wireless/ath/ath10k/debugfs_sta.c | 41 +
drivers/net/wireless/ath/ath10k/htt.c | 8 +-
drivers/net/wireless/ath/ath10k/htt.h | 169 +++-
drivers/net/wireless/ath/ath10k/htt_rx.c | 54 +-
drivers/net/wireless/ath/ath10k/htt_tx.c | 146 ++-
drivers/net/wireless/ath/ath10k/hw.c | 39 +
drivers/net/wireless/ath/ath10k/hw.h | 24 +-
drivers/net/wireless/ath/ath10k/mac.c | 57 +-
drivers/net/wireless/ath/ath10k/pci.c | 171 ++--
drivers/net/wireless/ath/ath10k/pci.h | 49 +
drivers/net/wireless/ath/ath10k/targaddrs.h | 3 +
drivers/net/wireless/ath/ath10k/trace.h | 15 +-
drivers/net/wireless/ath/ath10k/wmi-ops.h | 11 +
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 1 +
drivers/net/wireless/ath/ath10k/wmi.c | 162 +++-
drivers/net/wireless/ath/ath10k/wmi.h | 92 +-
drivers/net/wireless/ath/ath9k/ani.c | 36 +-
drivers/net/wireless/ath/ath9k/ar9003_aic.c | 79 +-
drivers/net/wireless/ath/ath9k/ar9003_aic.h | 1 -
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 6 +-
drivers/net/wireless/ath/ath9k/ar9003_hw.c | 3 +
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 12 +-
drivers/net/wireless/ath/ath9k/ar9003_phy.h | 3 +
drivers/net/wireless/ath/ath9k/ar953x_initvals.h | 65 ++
drivers/net/wireless/ath/ath9k/calib.c | 38 +-
drivers/net/wireless/ath/ath9k/channel.c | 4 +-
drivers/net/wireless/ath/ath9k/hif_usb.c | 2 +
drivers/net/wireless/ath/ath9k/hw.c | 10 +
drivers/net/wireless/ath/ath9k/init.c | 25 +-
drivers/net/wireless/ath/ath9k/main.c | 5 +-
drivers/net/wireless/ath/ath9k/reg.h | 4 +-
drivers/net/wireless/ath/carl9170/fwcmd.h | 8 +
drivers/net/wireless/ath/carl9170/fwdesc.h | 6 +
drivers/net/wireless/ath/carl9170/hw.h | 73 +-
drivers/net/wireless/ath/carl9170/version.h | 6 +-
drivers/net/wireless/ath/wil6210/cfg80211.c | 162 +++-
drivers/net/wireless/ath/wil6210/debugfs.c | 6 +-
drivers/net/wireless/ath/wil6210/main.c | 112 +--
drivers/net/wireless/ath/wil6210/netdev.c | 5 +-
drivers/net/wireless/ath/wil6210/txrx.c | 46 +-
drivers/net/wireless/ath/wil6210/wil6210.h | 11 +-
drivers/net/wireless/ath/wil6210/wmi.c | 174 +++-
drivers/net/wireless/atmel/at76c50x-usb.c | 2 -
drivers/net/wireless/broadcom/b43/main.c | 6 +-
.../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 105 +--
.../net/wireless/broadcom/brcm80211/brcmfmac/bus.h | 4 +-
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 617 ++++++++-----
.../broadcom/brcm80211/brcmfmac/cfg80211.h | 20 +-
.../wireless/broadcom/brcm80211/brcmfmac/common.c | 152 +++-
.../wireless/broadcom/brcm80211/brcmfmac/common.h | 43 +-
.../wireless/broadcom/brcm80211/brcmfmac/core.c | 180 +++-
.../wireless/broadcom/brcm80211/brcmfmac/core.h | 9 +
.../wireless/broadcom/brcm80211/brcmfmac/feature.c | 14 +
.../wireless/broadcom/brcm80211/brcmfmac/feature.h | 10 +-
.../broadcom/brcm80211/brcmfmac/flowring.c | 38 +-
.../broadcom/brcm80211/brcmfmac/flowring.h | 20 +-
.../wireless/broadcom/brcm80211/brcmfmac/fweh.c | 57 +-
.../wireless/broadcom/brcm80211/brcmfmac/fweh.h | 68 +-
.../broadcom/brcm80211/brcmfmac/fwil_types.h | 29 +-
.../wireless/broadcom/brcm80211/brcmfmac/msgbuf.c | 11 +-
.../wireless/broadcom/brcm80211/brcmfmac/msgbuf.h | 2 +-
.../net/wireless/broadcom/brcm80211/brcmfmac/of.c | 22 +-
.../net/wireless/broadcom/brcm80211/brcmfmac/of.h | 4 +-
.../net/wireless/broadcom/brcm80211/brcmfmac/p2p.c | 26 +-
.../wireless/broadcom/brcm80211/brcmfmac/pcie.c | 206 ++---
.../wireless/broadcom/brcm80211/brcmfmac/sdio.c | 103 ++-
.../wireless/broadcom/brcm80211/brcmfmac/sdio.h | 2 +-
.../net/wireless/broadcom/brcm80211/brcmfmac/usb.c | 16 +-
.../broadcom/brcm80211/include/brcmu_wifi.h | 2 +
drivers/net/wireless/intel/iwlwifi/iwl-7000.c | 4 +-
drivers/net/wireless/intel/iwlwifi/iwl-8000.c | 5 +-
drivers/net/wireless/intel/iwlwifi/iwl-9000.c | 5 +-
drivers/net/wireless/intel/iwlwifi/iwl-config.h | 2 +
drivers/net/wireless/intel/iwlwifi/iwl-csr.h | 49 +
.../wireless/intel/iwlwifi/iwl-devtrace-iwlwifi.h | 4 +-
drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 7 +-
drivers/net/wireless/intel/iwlwifi/iwl-fh.h | 24 +-
drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h | 10 +
drivers/net/wireless/intel/iwlwifi/iwl-modparams.h | 2 +
drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 5 +-
drivers/net/wireless/intel/iwlwifi/iwl-prph.h | 2 +
drivers/net/wireless/intel/iwlwifi/iwl-trans.h | 1 +
drivers/net/wireless/intel/iwlwifi/mvm/d3.c | 6 +-
drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c | 24 +-
drivers/net/wireless/intel/iwlwifi/mvm/fw-api-rx.h | 52 ++
drivers/net/wireless/intel/iwlwifi/mvm/fw-api.h | 126 ++-
drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 32 +-
drivers/net/wireless/intel/iwlwifi/mvm/mac-ctxt.c | 2 +
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 84 +-
drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 109 ++-
drivers/net/wireless/intel/iwlwifi/mvm/ops.c | 94 +-
drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 25 +-
drivers/net/wireless/intel/iwlwifi/mvm/rx.c | 63 +-
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 146 ++-
drivers/net/wireless/intel/iwlwifi/mvm/scan.c | 36 +-
drivers/net/wireless/intel/iwlwifi/mvm/sta.c | 34 +-
drivers/net/wireless/intel/iwlwifi/mvm/sta.h | 23 +-
drivers/net/wireless/intel/iwlwifi/mvm/tt.c | 461 +++++++++-
drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 195 +++-
drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 41 +
drivers/net/wireless/intel/iwlwifi/pcie/internal.h | 100 ++-
drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 206 ++++-
drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 277 ++++--
drivers/net/wireless/intel/iwlwifi/pcie/tx.c | 10 +-
drivers/net/wireless/marvell/mwifiex/11h.c | 6 +-
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 2 +-
drivers/net/wireless/marvell/mwifiex/ioctl.h | 6 +
drivers/net/wireless/marvell/mwifiex/main.h | 5 +
drivers/net/wireless/marvell/mwifiex/pcie.c | 4 +-
drivers/net/wireless/marvell/mwifiex/sdio.c | 16 +
drivers/net/wireless/marvell/mwifiex/sta_ioctl.c | 1 +
drivers/net/wireless/marvell/mwifiex/tdls.c | 7 +
drivers/net/wireless/marvell/mwifiex/uap_cmd.c | 2 +-
drivers/net/wireless/marvell/mwifiex/usb.c | 4 +-
drivers/net/wireless/marvell/mwifiex/util.c | 20 +
drivers/net/wireless/mediatek/mt7601u/mcu.c | 4 +-
drivers/net/wireless/ralink/rt2x00/rt2800usb.c | 1 +
drivers/net/wireless/ralink/rt2x00/rt2x00debug.c | 5 +-
drivers/net/wireless/realtek/rtl8xxxu/Kconfig | 2 +-
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.c | 183 ++--
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 2 +-
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_regs.h | 55 +-
drivers/net/wireless/realtek/rtlwifi/core.c | 60 +-
drivers/net/wireless/realtek/rtlwifi/pci.c | 3 +-
drivers/net/wireless/realtek/rtlwifi/rc.c | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/trx.c | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8188ee/trx.h | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8192de/phy.c | 23 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/hw.c | 12 -
.../net/wireless/realtek/rtlwifi/rtl8192ee/trx.c | 6 +-
.../net/wireless/realtek/rtlwifi/rtl8192ee/trx.h | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/trx.c | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8723ae/trx.h | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/trx.c | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8723be/trx.h | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/fw.c | 2 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/hw.c | 20 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/phy.c | 27 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/trx.c | 4 +-
.../net/wireless/realtek/rtlwifi/rtl8821ae/trx.h | 2 +-
drivers/net/wireless/realtek/rtlwifi/wifi.h | 22 +-
drivers/net/wireless/st/cw1200/cw1200_spi.c | 9 +-
drivers/net/wireless/st/cw1200/pm.h | 9 +-
include/linux/bcma/bcma_driver_chipcommon.h | 11 +-
include/linux/platform_data/brcmfmac-sdio.h | 135 ---
include/linux/platform_data/brcmfmac.h | 185 ++++
162 files changed, 6439 insertions(+), 1820 deletions(-)
create mode 100644 drivers/bcma/driver_chipcommon_pflash.c
create mode 100644 drivers/net/wireless/ath/ath10k/ahb.c
create mode 100644 drivers/net/wireless/ath/ath10k/ahb.h
delete mode 100644 include/linux/platform_data/brcmfmac-sdio.h
create mode 100644 include/linux/platform_data/brcmfmac.h
--
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: [RFC] net: ipv4 -- Introduce ifa limit per net
From: Cyrill Gorcunov @ 2016-03-09 19:55 UTC (permalink / raw)
To: David Miller, alexei.starovoitov, eric.dumazet
Cc: netdev, solar, vvs, avagin, xemul, vdavydov, khorenko
In-Reply-To: <20160309175307.GM2207@uranus.lan>
On Wed, Mar 09, 2016 at 08:53:07PM +0300, Cyrill Gorcunov wrote:
> On Wed, Mar 09, 2016 at 12:24:00PM -0500, David Miller wrote:
> ...
> > We asked you for numbers without a lot of features enabled, it'll
> > help us diagnose which subsystem still causes a lot of overhead
> > much more clearly.
> >
> > So please do so.
>
> Sure. Gimme some time and I'll back with numbers.
OK, here are the results (with preempt-debug/trace disabled,
on the kernel with David's two patches).
---
No conntrack
------------
[root@s125 ~]# ./exploit.sh
START 4 addresses STOP 1457549979 1457549980 -> 1
START 2704 addresses STOP 1457549983 1457549984 -> 1
START 10404 addresses STOP 1457549996 1457549997 -> 1
START 23104 addresses STOP 1457550029 1457550030 -> 1
START 40804 addresses STOP 1457550103 1457550104 -> 1
START 63504 addresses STOP 1457550267 1457550268 -> 1
all works quite fast, takes 1 second.
With conntrack
--------------
1) In a middle of "release -> create new addresses" transition
27.53% [kernel] [k] __local_bh_enable_ip
26.29% [kernel] [k] _raw_spin_lock
6.00% [kernel] [k] nf_ct_iterate_cleanup
3.95% [kernel] [k] nf_conntrack_lock
2.94% [kernel] [k] _raw_spin_unlock
1.91% [kernel] [k] _cond_resched
1.78% [kernel] [k] check_lifetime
1.25% [kernel] [k] __inet_insert_ifa
1.19% [kernel] [k] inet_rtm_newaddr
2) Last one with 63K of addresses releasing
36.36% [kernel] [k] __local_bh_enable_ip
34.75% [kernel] [k] _raw_spin_lock
7.93% [kernel] [k] nf_ct_iterate_cleanup
5.11% [kernel] [k] nf_conntrack_lock
3.71% [kernel] [k] _raw_spin_unlock
2.51% [kernel] [k] _cond_resched
0.89% [kernel] [k] task_tick_fair
0.77% [kernel] [k] native_write_msr_safe
0.58% [kernel] [k] hrtimer_active
0.52% [kernel] [k] rcu_check_callbacks
[root@s125 ~]# ./exploit.sh
START 4 addresses STOP 1457552395 1457552397 -> 2
START 2704 addresses STOP 1457552399 1457552403 -> 4
START 10404 addresses STOP 1457552415 1457552429 -> 14
START 23104 addresses STOP 1457552461 1457552492 -> 31
START 40804 addresses STOP 1457552566 1457552620 -> 54
START 63504 addresses STOP 1457552785 1457552870 -> 85
at the final stage it took 85 seconds to become alive. All
eaten inside nf_ct_iterate_cleanup (actually inside
get_next_corpse). IIRC there were some feature of perf
which could annotate the instructions, no? Have to refresh
memory on how to use perf record and such...
^ 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