* Re: [PATCH][V2] net: sctp: fix array overrun read on sctp_timer_tbl
From: David Miller @ 2017-01-20 16:52 UTC (permalink / raw)
To: marcelo.leitner
Cc: colin.king, vyasevich, nhorman, linux-sctp, netdev, linux-kernel
In-Reply-To: <20170120164820.GA669@localhost.localdomain>
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Date: Fri, 20 Jan 2017 14:48:20 -0200
> Seems you applied it on net tree, but commit that introduced the issue
> (7b9438de0cd4) is still only on net-next.
That explains everything.
> I build-tested it here before acking, it worked, on top of
> 4567d686f5c6d955e57a3afa1741944c1e7f4033.
>
> Colin, please respin the patch.. add the Fixes tag, fix the missing 'o'
> in my name on the changelog :-) and tag the patch as net-next tree too.
Indeed, thanks.
^ permalink raw reply
* Re: [RFC] net: ipv6: return the first matched rt6_info for multicast packets in find_rr_leaf()
From: David Miller @ 2017-01-20 16:58 UTC (permalink / raw)
To: sekraj; +Cc: kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel
In-Reply-To: <20170118151337.mcub5vyjszy5ltyn@extreme-Latitude-E4310>
From: Rajasekar Kumar <sekraj@gmail.com>
Date: Wed, 18 Jan 2017 20:43:37 +0530
> There is a performance issue when large number of interfaces are
> enabled with VRRP protocol in 2 router nodes which are connected
> to each other. When VRRP hello is received (which is multicast
> packet with DIP: ff02::18), a rt6_info node is added to fib6_node
> of address ff02::18. This happens for each interface on which
> VRRP is enabled. For 2000 interfaces with VRRP enabled, 2000
> rt6_info nodes are added to the same fib6_node. As of today,
> find_rr_leaf() goes further to find better match, even after first
> successful match based on interface key. In this case, it walks
> 2000 nodes for every incoming packet/outgoing packet, which is
> expensive and not needed. rt6_info match based on supplied
> interface match should be sufficient. The first match occurs
> when there is interface match, and after that there can not be
> another match for multicast packets. So, first match should be
> returned for multicast packets.
>
> find_rr_leaf() tries to find best available gateway, mainly based on
> interface match and gateway's reachablity info.When this is required
> for unicast packets, multicast packets do not need either gateway's
> reachability status or gateway's Layer2 address as it is derived
> from Destination IP (group address). rt6_info match based on supplied
> interface match should be sufficient.
>
> This fix helps in scenario wherein multicast packets arrive in some
> interfaces frequently than other interfaces. rt6_info is added to
> beginning of list for former cases. Verified this case.
>
> Signed-off-by: Rajasekar Kumar <sekraj@gmail.com>
So the only thing different in each rt6_info in the list is the
interface, right?
Well, that's a part of the lookup key, multicast or not. If the user
binds a socket to a specific interface, they want the route lookup to
return the rt6_info node with that device.
So I think your change introduces a regression, therefore another
solution will need to be found for your performance problem.
^ permalink raw reply
* Re: [net-next PATCH 0/3] Retrieve number of VFs in a bus-agnostic way
From: Phil Sutter @ 2017-01-20 16:59 UTC (permalink / raw)
To: David Miller; +Cc: bhelgaas, netdev, linux-pci
In-Reply-To: <20170120.114346.786441265338417344.davem@davemloft.net>
On Fri, Jan 20, 2017 at 11:43:46AM -0500, David Miller wrote:
> From: Phil Sutter <phil@nwl.cc>
> Date: Wed, 18 Jan 2017 14:04:36 +0100
>
> > Previously, it was assumed that only PCI NICs would be capable of having
> > virtual functions - with my proposed enhancement of dummy NIC driver
> > implementing (fake) ones for testing purposes, this is no longer true.
> >
> > Discussion of said patch has led to the suggestion of implementing a
> > bus-agnostic method for VF count retrieval so rtnetlink could work with
> > both real VF-capable PCI NICs as well as my dummy modifications without
> > introducing ugly hacks.
> >
> > The following series tries to achieve just that by introducing a bus
> > type callback to retrieve a device's number of VFs, implementing this
> > callback for PCI bus and finally adjusting rtnetlink to make use of the
> > generalized infrastructure.
>
> This is really nice and clean, compare it to your original approach :-)
Yes, indeed! Thanks a lot for pointing me into the right direction. :)
Cheers, Phil
^ permalink raw reply
* RE: [net PATCH v5 6/6] virtio_net: XDP support for adjust_head
From: David Laight @ 2017-01-20 16:59 UTC (permalink / raw)
To: 'Michael S. Tsirkin', Jason Wang
Cc: John Fastabend, john.r.fastabend@intel.com,
netdev@vger.kernel.org, alexei.starovoitov@gmail.com,
daniel@iogearbox.net
In-Reply-To: <20170119231027-mutt-send-email-mst@kernel.org>
From: Michael S. Tsirkin
> Sent: 19 January 2017 21:12
> > On 2017?01?18? 23:15, Michael S. Tsirkin wrote:
> > > On Tue, Jan 17, 2017 at 02:22:59PM -0800, John Fastabend wrote:
> > > > Add support for XDP adjust head by allocating a 256B header region
> > > > that XDP programs can grow into. This is only enabled when a XDP
> > > > program is loaded.
> > > >
> > > > In order to ensure that we do not have to unwind queue headroom push
> > > > queue setup below bpf_prog_add. It reads better to do a prog ref
> > > > unwind vs another queue setup call.
> > > >
> > > > At the moment this code must do a full reset to ensure old buffers
> > > > without headroom on program add or with headroom on program removal
> > > > are not used incorrectly in the datapath. Ideally we would only
> > > > have to disable/enable the RX queues being updated but there is no
> > > > API to do this at the moment in virtio so use the big hammer. In
> > > > practice it is likely not that big of a problem as this will only
> > > > happen when XDP is enabled/disabled changing programs does not
> > > > require the reset. There is some risk that the driver may either
> > > > have an allocation failure or for some reason fail to correctly
> > > > negotiate with the underlying backend in this case the driver will
> > > > be left uninitialized. I have not seen this ever happen on my test
> > > > systems and for what its worth this same failure case can occur
> > > > from probe and other contexts in virtio framework.
> > > >
> > > > Signed-off-by: John Fastabend<john.r.fastabend@intel.com>
> > > I've been thinking about it - can't we drop
> > > old buffers without the head room which were posted before
> > > xdp attached?
> > >
> > > Avoiding the reset would be much nicer.
> > >
> > > Thoughts?
> > >
> >
> > As been discussed before, device may use them in the same time so it's not
> > safe. Or do you mean detect them after xdp were set and drop the buffer
> > without head room, this looks sub-optimal.
> >
> > Thanks
>
> Yes, this is what I mean. Why is this suboptimal? It's a single branch
> in code. Yes we might lose some packets but the big hammer of device
> reset will likely lose more.
Why not leave let the hardware receive into the 'small' buffer (without
headroom) and do a copy when a frame is received.
Replace the buffers with 'big' ones for the next receive.
A data copy on a ring full of buffers won't really be noticed.
David
^ permalink raw reply
* [PATCH net v2] bridge: netlink: call br_changelink() during br_dev_newlink()
From: Ivan Vecera @ 2017-01-20 16:59 UTC (permalink / raw)
To: netdev; +Cc: stephen, davem, bridge, jiri
Any bridge options specified during link creation (e.g. ip link add)
are ignored as br_dev_newlink() does not process them.
Use br_changelink() to do it.
Fixes: 1332351 bridge: implement rtnl_link_ops->changelink
Signed-off-by: Ivan Vecera <cera@cera.cz>
---
net/bridge/br_netlink.c | 33 +++++++++++++++++++--------------
1 file changed, 19 insertions(+), 14 deletions(-)
diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
index 71c7453..7109b38 100644
--- a/net/bridge/br_netlink.c
+++ b/net/bridge/br_netlink.c
@@ -781,20 +781,6 @@ static int br_validate(struct nlattr *tb[], struct nlattr *data[])
return 0;
}
-static int br_dev_newlink(struct net *src_net, struct net_device *dev,
- struct nlattr *tb[], struct nlattr *data[])
-{
- struct net_bridge *br = netdev_priv(dev);
-
- if (tb[IFLA_ADDRESS]) {
- spin_lock_bh(&br->lock);
- br_stp_change_bridge_id(br, nla_data(tb[IFLA_ADDRESS]));
- spin_unlock_bh(&br->lock);
- }
-
- return register_netdevice(dev);
-}
-
static int br_port_slave_changelink(struct net_device *brdev,
struct net_device *dev,
struct nlattr *tb[],
@@ -1115,6 +1101,25 @@ static int br_changelink(struct net_device *brdev, struct nlattr *tb[],
return 0;
}
+static int br_dev_newlink(struct net *src_net, struct net_device *dev,
+ struct nlattr *tb[], struct nlattr *data[])
+{
+ struct net_bridge *br = netdev_priv(dev);
+ int err;
+
+ if (tb[IFLA_ADDRESS]) {
+ spin_lock_bh(&br->lock);
+ br_stp_change_bridge_id(br, nla_data(tb[IFLA_ADDRESS]));
+ spin_unlock_bh(&br->lock);
+ }
+
+ err = br_changelink(dev, tb, data);
+ if (err)
+ return err;
+
+ return register_netdevice(dev);
+}
+
static size_t br_get_size(const struct net_device *brdev)
{
return nla_total_size(sizeof(u32)) + /* IFLA_BR_FORWARD_DELAY */
--
2.10.2
^ permalink raw reply related
* Re: [PATCH net 0/2] net: Fix oops on state free after lwt module unload
From: David Miller @ 2017-01-20 17:03 UTC (permalink / raw)
To: rshearma; +Cc: netdev, tom, roopa
In-Reply-To: <1484753523-26230-1-git-send-email-rshearma@brocade.com>
From: Robert Shearman <rshearma@brocade.com>
Date: Wed, 18 Jan 2017 15:32:01 +0000
> This patchset fixes an oops in lwtstate_free and a memory leak that
> would otherwise be exposed by ensuring that references are taken on
> modules that need to stay around to clean up lwt state. To faciliate
> this all ops that implement destroy_state and that can be configured
> to build as a module are changed specify the owner module in the
> ops. The intersection of those two sets is just ila at the moment.
Two things:
1) Under no circumstances should we allow a lwtunnel ops implementing
module to unload while there is a rule using those ops which is
alive.
Therefore, we should not special case the destroy op. We should
unconditionally grab the module reference.
2) Please add the new 'owner' field and add an appropriate assignment
for ops->owner to _every_ lwtunnel implementation, and do so in
your first patch. Please do not only do this for ILA.
Thanks.
^ permalink raw reply
* Re: [PATCH v5 0/2] Add support for the ethernet switch on the ESPRESSObin
From: Gregory CLEMENT @ 2017-01-20 17:08 UTC (permalink / raw)
To: Andrew Lunn
Cc: Vivien Didelot, Florian Fainelli, netdev, linux-kernel,
David S. Miller, Jason Cooper, Sebastian Hesselbarth,
Thomas Petazzoni, linux-arm-kernel, Nadav Haklai, Wilson Ding,
Kostya Porotchkin, Joe Zhou, Jon Pannell
In-Reply-To: <20170119220607.GA25907@lunn.ch>
Hi Andrew,
On jeu., janv. 19 2017, Andrew Lunn <andrew@lunn.ch> wrote:
>> While comparing the datasheet and the ops functions used, some
>> question came to me. They should not prevent applying this series,
>> but their answer would help me to have a better understanding of the
>> dsa subsystem.
>>
>> - Are the temperature related operation still useful with dsa2 ?
>
> No. I'm in the process of moving the code into the Marvell PHY driver,
> since the sensor is in the embedded PHYs.
>
> What ID does the embedded PHY use? The 6390 has a blank ID, where as
> older device have a real ID.
Actually I didn't find anything related to the temperature measurement
in the datasheet I have. For the 6390 there is a dedicated datsheet for
the PHY part for the 6352 it is part of the same datasheet.
After a second look I think I don't have anything related to the PHY
part in the datasheets.
What I wanted to do was to test 6390 and 6352 temperature related
functions and to see if one of them worked. That's how I realized it was
not possible to do it with dsa2.
>
>> - Why the setup is done differently between the 6390 and the 6352
>> families when the have exactly the same register?
>
> EDSA on 6390 works differently to 6352, meaning it breaks. So we need
> to run the 6390 with DSA tagging, not EDSA. Maybe this is the source
> of the differences?
>
> It should also be noted that the 6390 support is not yet complete. I
> have a few more patches in my tree to post.
>
>> - On the Port Controller 2, the bit PORT_CONTROL_2_MAP_DA is set for
>> 6352 and not for 6390 whereas the same bit exists in 6360 and the
>> description for this bit is the same for both datasheet.
>
> Humm, it does look like it is missing mv88e6xxx_6390_family(chip).
>
>>
>> - Register PORT_ATU_CONTROL and PORT_PRI_OVERRIDE are reset on 6352
>> and not on 6390. While here again the registers description are
>> the same.
>
> And the same here. I've mostly been working on where the 6390 is
> different. Where it is the same i've mostly ignored it so far :-)
>
> There is also an ongoing effort to remove all these big if statements
> with a list of families.
Thanks for this answers I understand it a little better now.
Gregory
>
> Andrew
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH net v2] bridge: netlink: call br_changelink() during br_dev_newlink()
From: Jiri Pirko @ 2017-01-20 17:08 UTC (permalink / raw)
To: Ivan Vecera; +Cc: netdev, stephen, davem, bridge, jiri
In-Reply-To: <20170120165933.19991-1-cera@cera.cz>
Fri, Jan 20, 2017 at 05:59:33PM CET, cera@cera.cz wrote:
>Any bridge options specified during link creation (e.g. ip link add)
>are ignored as br_dev_newlink() does not process them.
>Use br_changelink() to do it.
>
>Fixes: 1332351 bridge: implement rtnl_link_ops->changelink
This is not the correct "Fixes" format.
^ permalink raw reply
* Re: [PATCH net-next] bpf: add bpf_probe_read_str helper
From: David Miller @ 2017-01-20 17:09 UTC (permalink / raw)
To: g.borello; +Cc: daniel, ast, netdev
In-Reply-To: <20170118175549.15819-1-g.borello@gmail.com>
From: Gianluca Borello <g.borello@gmail.com>
Date: Wed, 18 Jan 2017 17:55:49 +0000
> Provide a simple helper with the same semantics of strncpy_from_unsafe():
>
> int bpf_probe_read_str(void *dst, int size, const void *unsafe_addr)
>
> This gives more flexibility to a bpf program.
...
> Signed-off-by: Gianluca Borello <g.borello@gmail.com>
> Acked-by: Alexei Starovoitov <ast@kernel.org>
> Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Applied, thank you.
^ permalink raw reply
* Re: [net-next 0/4] tipc: emulate multicast through replication
From: David Miller @ 2017-01-20 17:10 UTC (permalink / raw)
To: jon.maloy; +Cc: netdev, tipc-discussion
In-Reply-To: <1484765453-16258-1-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Wed, 18 Jan 2017 13:50:49 -0500
> TIPC multicast messages are currently distributed via L2 broadcast
> or IP multicast to all nodes in the cluster, irrespective of the
> number of real destinations of the message.
>
> In this series we introduce an option to transport messages via
> replication ("replicast") across a selected number of unicast links,
> instead of relying on the underlying media. This option is used when
> true broadcast/multicast is not supported by the media, or when the
> number of true destinations is much smaller than the cluster size.
Series applied, thanks Jon.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
^ permalink raw reply
* [PATCH net v3] bridge: netlink: call br_changelink() during br_dev_newlink()
From: Ivan Vecera @ 2017-01-20 17:12 UTC (permalink / raw)
To: netdev; +Cc: stephen, davem, bridge, jiri
Any bridge options specified during link creation (e.g. ip link add)
are ignored as br_dev_newlink() does not process them.
Use br_changelink() to do it.
Fixes: 1332351 ("bridge: implement rtnl_link_ops->changelink")
Signed-off-by: Ivan Vecera <cera@cera.cz>
---
net/bridge/br_netlink.c | 33 +++++++++++++++++++--------------
1 file changed, 19 insertions(+), 14 deletions(-)
diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
index 71c7453..7109b38 100644
--- a/net/bridge/br_netlink.c
+++ b/net/bridge/br_netlink.c
@@ -781,20 +781,6 @@ static int br_validate(struct nlattr *tb[], struct nlattr *data[])
return 0;
}
-static int br_dev_newlink(struct net *src_net, struct net_device *dev,
- struct nlattr *tb[], struct nlattr *data[])
-{
- struct net_bridge *br = netdev_priv(dev);
-
- if (tb[IFLA_ADDRESS]) {
- spin_lock_bh(&br->lock);
- br_stp_change_bridge_id(br, nla_data(tb[IFLA_ADDRESS]));
- spin_unlock_bh(&br->lock);
- }
-
- return register_netdevice(dev);
-}
-
static int br_port_slave_changelink(struct net_device *brdev,
struct net_device *dev,
struct nlattr *tb[],
@@ -1115,6 +1101,25 @@ static int br_changelink(struct net_device *brdev, struct nlattr *tb[],
return 0;
}
+static int br_dev_newlink(struct net *src_net, struct net_device *dev,
+ struct nlattr *tb[], struct nlattr *data[])
+{
+ struct net_bridge *br = netdev_priv(dev);
+ int err;
+
+ if (tb[IFLA_ADDRESS]) {
+ spin_lock_bh(&br->lock);
+ br_stp_change_bridge_id(br, nla_data(tb[IFLA_ADDRESS]));
+ spin_unlock_bh(&br->lock);
+ }
+
+ err = br_changelink(dev, tb, data);
+ if (err)
+ return err;
+
+ return register_netdevice(dev);
+}
+
static size_t br_get_size(const struct net_device *brdev)
{
return nla_total_size(sizeof(u32)) + /* IFLA_BR_FORWARD_DELAY */
--
2.10.2
^ permalink raw reply related
* Re: [PATCH net-next] csum: eliminate sparse warning in remcsum_unadjust()
From: David Miller @ 2017-01-20 17:12 UTC (permalink / raw)
To: lrichard; +Cc: netdev
In-Reply-To: <1484770496-3401-1-git-send-email-lrichard@redhat.com>
From: Lance Richardson <lrichard@redhat.com>
Date: Wed, 18 Jan 2017 15:14:56 -0500
> Cast second parameter of csum_sub() from __sum16 to __wsum.
>
> Signed-off-by: Lance Richardson <lrichard@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] vxlan: preserve type of dst_port parm for encap_bypass_if_local()
From: David Miller @ 2017-01-20 17:12 UTC (permalink / raw)
To: lrichard; +Cc: netdev
In-Reply-To: <1484771097-5692-1-git-send-email-lrichard@redhat.com>
From: Lance Richardson <lrichard@redhat.com>
Date: Wed, 18 Jan 2017 15:24:57 -0500
> Eliminate sparse warning by maintaining type of dst_port
> as __be16.
>
> Signed-off-by: Lance Richardson <lrichard@redhat.com>
Applied.
^ permalink raw reply
* Re: Getting a handle on all these new NIC features
From: Tom Herbert @ 2017-01-20 17:06 UTC (permalink / raw)
To: Martin Habets; +Cc: Linux Kernel Network Developers
In-Reply-To: <9dcdea22-3692-1721-5951-f3a29d003e92@solarflare.com>
On Fri, Jan 20, 2017 at 8:36 AM, Martin Habets <mhabets@solarflare.com> wrote:
> Hi Tom,
>
> On 17/01/17 22:05, Tom Herbert wrote:
>> There was some discussion about the problems of dealing with the
>> explosion of NIC features in the mlx directory restructuring proposal,
>> but I think the is a deeper issue here that should be discussed.
>>
>> It's hard not to notice that there has been quite a proliferation of
>> NIC features in several drivers. This trend had resulted in very
>> complex driver code that may or may not segment individual features.
>> One visible manifestation of this is number of ndo functions which is
>> somewhere around seventy-five now.
>>
>> I suspect the vast majority of these advances NIC features (e.g.
>> bridging, UDP offloads, tc offload, etc.) are only relevant to some of
>> the people some of the time. The problem we have, in this case those
>> of us that are attempting to deploy and maintain NICs at scale, is
>> when we have to deal with the ramifications of these features being
>> intertwined with core driver functionality that is relevant to
>> everyone. This becomes very obvious when we need to backport drivers
>> from later versions of kernel.
>>
>> I realize that backports of a driver is not a specific concern of the
>> Linux kernel, but nevertheless this is a real problem and a fact of
>> life for many users. Rebasing the full kernel is still a major effort
>> and it seems the best we could ever do is one rebase per year. In the
>> interim we need to occasionally backport drivers. Backporting drivers
>> is difficult precisely because of new features or API changes to
>> existing ones. These sort of changes tend to have a spiderweb of
>> dependencies in other parts of the stack so that the number of patches
>> we need to cherry-pick goes way beyond those that touch the driver we
>> are interested in.
>
> For the sfc driver (Solarflare Adapters) we currently do backports internally for:
> - RedHat Enterprise Linux 5.10, 5.11
> - RedHat Enterprise Linux 6.5, 6.6, 6.7, 6.8
> - Redhat Messaging Realtime and Grid 2.5
> - RedHat Enterprise Linux 7.0, 7.1, 7.2
> - RedHat Enterprise Linux for Realtime 7.1, 7.2
> - SuSE Linux Enterprise Server 11 sp3, sp4
> - SuSE Linux Enterprise RealTime Extension 11
> - SuSE Linux Enterprise Server 12 base release, sp1
> - Canonical Ubuntu Server LTS 14.04, 16.04
> - Canonical Ubuntu Server -
> - Debian 7 "Wheezy" 7.X
> - Debian 8 "Jessie" 8.X
> - Linux 2.6.18 to 4.9-rc1
>
> We update this list as needed, and always try to support the latest kernel.
> I do not know if that would cover the kernel version you are using.
>
That really doesn't help us. We don't base which kernels we run in
datacenters on what distros are doing-- they don't seem to move as
fast in rebsing. Our general request is that vendors always do their
development upstream, if we need to do a backport in our kernel then
we take responsibility for that. As I mentioned, the churn and lack of
modularization seem to be making this process more and more difficult.
Tom
> Best regards,
> Martin
>
>> Currently we (FB) need to backport two NIC drivers. I've already gave
>> details of backporting mlx5 on the thread to restructure the driver
>> directories. The other driver being backporting seems to suffer from
>> the same type of feature complexity.
>>
>> In short, I would like to ask if driver maintainers to start to
>> modularize driver features. If something being added is obviously a
>> narrow feature that only a subset of users will need can we allow
>> config options to #ifdef those out somehow? Furthermore can the file
>> and directory structure of drivers reflect that; our lives would be
>> _so_ much simpler to maintain drivers in production if we have such
>> modularity and the ability to build drivers with the features of our
>> choosing.
>>
>> Thanks,
>> Tom
^ permalink raw reply
* Re: [PATCH net-next] fq_codel: Avoid regenerating skb flow hash unless necessary
From: David Miller @ 2017-01-20 17:15 UTC (permalink / raw)
To: acollins; +Cc: netdev, eric.dumazet, tom
In-Reply-To: <20170118210428.24006-1-acollins@cradlepoint.com>
From: Andrew Collins <acollins@cradlepoint.com>
Date: Wed, 18 Jan 2017 14:04:28 -0700
> The fq_codel qdisc currently always regenerates the skb flow hash.
> This wastes some cycles and prevents flow seperation in cases where
> the traffic has been encrypted and can no longer be understood by the
> flow dissector.
>
> Change it to use the prexisting flow hash if one exists, and only
> regenerate if necessary.
>
> Signed-off-by: Andrew Collins <acollins@cradlepoint.com>
Applied, thanks.
^ permalink raw reply
* Re: [net PATCH] bpf: fix samples xdp_tx_iptunnel and tc_l2_redirect with fake KBUILD_MODNAME
From: David Miller @ 2017-01-20 17:04 UTC (permalink / raw)
To: brouer; +Cc: netdev, borkmann, kafai, alexei.starovoitov
In-Reply-To: <148475634058.19645.17347886661194782120.stgit@firesoul>
From: Jesper Dangaard Brouer <brouer@redhat.com>
Date: Wed, 18 Jan 2017 17:19:00 +0100
> Fix build errors for samples/bpf xdp_tx_iptunnel and tc_l2_redirect,
> when dynamic debugging is enabled (CONFIG_DYNAMIC_DEBUG) by defining a
> fake KBUILD_MODNAME.
>
> Just like Daniel Borkmann fixed other samples/bpf in commit
> 96a8eb1eeed2 ("bpf: fix samples to add fake KBUILD_MODNAME").
>
> Fixes: 12d8bb64e3f6 ("bpf: xdp: Add XDP example for head adjustment")
> Fixes: 90e02896f1a4 ("bpf: Add test for bpf_redirect to ipip/ip6tnl")
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Applied, thanks Jesper.
^ permalink raw reply
* Re: [PATCH] net: qcom/emac: claim the irq only when the device is opened
From: David Miller @ 2017-01-20 17:19 UTC (permalink / raw)
To: timur; +Cc: netdev
In-Reply-To: <1484775745-14050-1-git-send-email-timur@codeaurora.org>
From: Timur Tabi <timur@codeaurora.org>
Date: Wed, 18 Jan 2017 15:42:25 -0600
> During reset, functions emac_mac_down() and emac_mac_up() are called,
> so we don't want to free and claim the IRQ unnecessarily. Move those
> operations to open/close.
>
> Signed-off-by: Timur Tabi <timur@codeaurora.org>
If you don't tell me what tree this is against in your Subject line,
I have to guess.
I don't like guessing.
^ permalink raw reply
* Re: [PATCH v5 2/2] net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341
From: Gregory CLEMENT @ 2017-01-20 17:21 UTC (permalink / raw)
To: Vivien Didelot, Andrew Lunn
Cc: Thomas Petazzoni, Florian Fainelli, Jason Cooper, Joe Zhou,
netdev, linux-kernel, Jon Pannell, Nadav Haklai,
Kostya Porotchkin, Wilson Ding, David S. Miller, linux-arm-kernel,
Sebastian Hesselbarth
In-Reply-To: <20170120001203.GB31483@lunn.ch>
Hi Vvien and Andrew,
On ven., janv. 20 2017, Andrew Lunn <andrew@lunn.ch> wrote:
> On Thu, Jan 19, 2017 at 05:26:03PM -0500, Vivien Didelot wrote:
>> Gregory CLEMENT <gregory.clement@free-electrons.com> writes:
>>
>> > +static bool mv88e6xxx_6341_family(struct mv88e6xxx_chip *chip)
>> > +{
>> > + return chip->info->family == MV88E6XXX_FAMILY_6341;
>> > +}
>>
>> I don't want to see these erronous family checks anymore, but I cannot
>> blame you for adding it since not all the code is moved to ops yet ;)
If there a series about to be merged I can rebase my series on it. Else
I propose to keep it and convert the family check to ops when you will
send the series for it.
>>
>> > MV88E6XXX_FAMILY_6165, /* 6123 6161 6165 */
>> > MV88E6XXX_FAMILY_6185, /* 6108 6121 6122 6131 6152 6155 6182 6185 */
>> > MV88E6XXX_FAMILY_6320, /* 6320 6321 */
>> > + MV88E6XXX_FAMILY_6341, /* 6141 6341 */
>>
>> Maybe I missed it, Andrew, can you confirm that 6341 is a proper Marvell
>> family of switch chips?
>
> My understand is that it is. Marvell have not added it to DSDT. There
> is a new SDK called UMSD, also GPLv2 and BSD. They call this family
> Topaz, and the 6390 is Peridot.
I confirm that 6141 and 6341 are called Topaz. Actually I can add the
support for the 6141 too, it is just a matter of adding an ID and maybe
removing some ops as 6141 is a subset of 6341.
Gregory
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH net-next] fq_codel: Avoid regenerating skb flow hash unless necessary
From: Tom Herbert @ 2017-01-20 17:23 UTC (permalink / raw)
To: Andrew Collins; +Cc: Linux Kernel Network Developers, Eric Dumazet
In-Reply-To: <20170118210428.24006-1-acollins@cradlepoint.com>
On Wed, Jan 18, 2017 at 1:04 PM, Andrew Collins
<acollins@cradlepoint.com> wrote:
> The fq_codel qdisc currently always regenerates the skb flow hash.
> This wastes some cycles and prevents flow seperation in cases where
> the traffic has been encrypted and can no longer be understood by the
> flow dissector.
>
> Change it to use the prexisting flow hash if one exists, and only
> regenerate if necessary.
>
> Signed-off-by: Andrew Collins <acollins@cradlepoint.com>
> ---
> net/sched/sch_fq_codel.c | 6 +-----
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/net/sched/sch_fq_codel.c b/net/sched/sch_fq_codel.c
> index a5ea0e9..2f50e4c 100644
> --- a/net/sched/sch_fq_codel.c
> +++ b/net/sched/sch_fq_codel.c
> @@ -57,7 +57,6 @@ struct fq_codel_sched_data {
> struct fq_codel_flow *flows; /* Flows table [flows_cnt] */
> u32 *backlogs; /* backlog table [flows_cnt] */
> u32 flows_cnt; /* number of flows */
> - u32 perturbation; /* hash perturbation */
> u32 quantum; /* psched_mtu(qdisc_dev(sch)); */
> u32 drop_batch_size;
> u32 memory_limit;
> @@ -75,9 +74,7 @@ struct fq_codel_sched_data {
> static unsigned int fq_codel_hash(const struct fq_codel_sched_data *q,
> struct sk_buff *skb)
> {
> - u32 hash = skb_get_hash_perturb(skb, q->perturbation);
> -
> - return reciprocal_scale(hash, q->flows_cnt);
> + return reciprocal_scale(skb_get_hash(skb), q->flows_cnt);
So the perturbing of the hash is no longer needed for fq_codel?
> }
>
> static unsigned int fq_codel_classify(struct sk_buff *skb, struct Qdisc *sch,
> @@ -482,7 +479,6 @@ static int fq_codel_init(struct Qdisc *sch, struct nlattr *opt)
> q->memory_limit = 32 << 20; /* 32 MBytes */
> q->drop_batch_size = 64;
> q->quantum = psched_mtu(qdisc_dev(sch));
> - q->perturbation = prandom_u32();
> INIT_LIST_HEAD(&q->new_flows);
> INIT_LIST_HEAD(&q->old_flows);
> codel_params_init(&q->cparams);
> --
> 2.9.3
>
^ permalink raw reply
* Re: [PATCH v5 2/2] net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341
From: Vivien Didelot @ 2017-01-20 17:30 UTC (permalink / raw)
To: Gregory CLEMENT, Andrew Lunn
Cc: Florian Fainelli, netdev, linux-kernel, David S. Miller,
Jason Cooper, Sebastian Hesselbarth, Thomas Petazzoni,
linux-arm-kernel, Nadav Haklai, Wilson Ding, Kostya Porotchkin,
Joe Zhou, Jon Pannell
In-Reply-To: <8760l9641t.fsf@free-electrons.com>
Hi Gregory,
Gregory CLEMENT <gregory.clement@free-electrons.com> writes:
> If there a series about to be merged I can rebase my series on it. Else
> I propose to keep it and convert the family check to ops when you will
> send the series for it.
I am reworking the VTU operations, but not these port operations yet.
I will take care of converting the family checks once I'm done, don't
worry ;)
> I confirm that 6141 and 6341 are called Topaz. Actually I can add the
> support for the 6141 too, it is just a matter of adding an ID and maybe
> removing some ops as 6141 is a subset of 6341.
I don't mind having a patch adding support for only one chip at a time,
that is up to you.
Thanks,
Vivien
^ permalink raw reply
* Re: [PATCH iproute2 0/2] two small fixes in flower option parser error flow
From: Stephen Hemminger @ 2017-01-20 17:30 UTC (permalink / raw)
To: Roi Dayan; +Cc: netdev, Amir Vadai, Jiri Pirko, Jamal Hadi Salim, Paul Blakey
In-Reply-To: <1484829080-18593-1-git-send-email-roid@mellanox.com>
On Thu, 19 Jan 2017 14:31:18 +0200
Roi Dayan <roid@mellanox.com> wrote:
> Hi,
>
> the first adds a missing return check and the second removes
> an incorrect error msg.
>
> Thanks,
> Roi
>
>
> Roi Dayan (2):
> tc: flower: Add missing err check when parsing flower options
> tc: flower: Fix incorrect error msg about eth type
>
> tc/f_flower.c | 11 +++++------
> 1 files changed, 5 insertions(+), 6 deletions(-)
>
Both applied
^ permalink raw reply
* Re: [PATCH] net: qcom/emac: claim the irq only when the device is opened
From: Timur Tabi @ 2017-01-20 17:22 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20170120.121901.1924570978922182141.davem@davemloft.net>
On 01/20/2017 11:19 AM, David Miller wrote:
> If you don't tell me what tree this is against in your Subject line,
> I have to guess.
>
> I don't like guessing.
Sorry, this is for net-next. I will specify the target tree in all future
patches.
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* Re: [PATCH next 0/3] use netdev_is_rx_handler_busy() in few known cases
From: David Miller @ 2017-01-20 17:22 UTC (permalink / raw)
To: mahesh; +Cc: edumazet, netdev, maheshb
In-Reply-To: <20170118230245.20674-1-mahesh@bandewar.net>
From: Mahesh Bandewar <mahesh@bandewar.net>
Date: Wed, 18 Jan 2017 15:02:45 -0800
> netdev_rx_handler_register() was recently split into two parts - (a) check
> if the handler is used, (b) register the new handler, parts. This is
> helpful in scenarios like bonding where at the time of registration there
> is too much state to unwind and it should check if the device is free
> before building that state. IPvlan and macvlan drivers don't have this
> issue however it can make use of the same check instead of using a device
> specific check.
Looks good, series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] fq_codel: Avoid regenerating skb flow hash unless necessary
From: Eric Dumazet @ 2017-01-20 17:31 UTC (permalink / raw)
To: Tom Herbert; +Cc: Andrew Collins, Linux Kernel Network Developers
In-Reply-To: <CALx6S37Pnjyz6cpykKgy5JOU23MkH4EJ2Z+do+zVfXR08X5NYg@mail.gmail.com>
On Fri, 2017-01-20 at 09:23 -0800, Tom Herbert wrote:
> So the perturbing of the hash is no longer needed for fq_codel?
Right, we never implemented a timer to change the perturbation anyway.
Note that local TCP flows now implement their own hash change when
needed.
^ permalink raw reply
* Re: [PATCH iproute2 net-next v2] tc: m_csum: add support for SCTP checksum
From: Stephen Hemminger @ 2017-01-20 17:32 UTC (permalink / raw)
To: Davide Caratti; +Cc: Gregoire Baron, Jiri Benc, netdev
In-Reply-To: <7e8e15a6e6f11133b4e22166d27d32ad8d5a83e7.1484906832.git.dcaratti@redhat.com>
On Fri, 20 Jan 2017 11:10:10 +0100
Davide Caratti <dcaratti@redhat.com> wrote:
> 'sctp' parameter can now be used as 'csum' target to enable CRC32c
> computation on SCTP packets.
>
> Signed-off-by: Davide Caratti <dcaratti@redhat.com>
Applied to net-next
^ 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