* 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
* Re: [PATCH] ip/xfrm: Fix deleteall when having many policies installed
From: Stephen Hemminger @ 2017-01-20 17:22 UTC (permalink / raw)
To: Alexander Heinlein; +Cc: netdev, shemminger
In-Reply-To: <51b5293a-bce8-b663-f9de-97dc7c8113b3@secunet.com>
On Thu, 19 Jan 2017 08:57:56 +0100
Alexander Heinlein <alexander.heinlein@secunet.com> wrote:
> From 192cf19b3a97871a508ad57ba5893d1719877f13 Mon Sep 17 00:00:00 2001
> From: Alexander Heinlein <alexander.heinlein@secunet.com>
> Date: Mon, 16 Jan 2017 14:48:25 +0100
> Subject: [PATCH] ip/xfrm: Fix deleteall when having many policies installed
>
> Fix "Policy buffer overflow" when trying to use deleteall with many
> policies installed.
>
> Signed-off-by: Alexander Heinlein <alexander.heinlein@secunet.com>
Applied thanks.
^ permalink raw reply
* Re: [PATCH v2 0/5] net: ethernet: ti: cpsw: correct common res usage
From: David Miller @ 2017-01-20 17:35 UTC (permalink / raw)
To: ivan.khoronzhuk
Cc: mugunthanvnm, grygorii.strashko, netdev, linux-omap, linux-kernel
In-Reply-To: <1484845107-30331-1-git-send-email-ivan.khoronzhuk@linaro.org>
From: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Date: Thu, 19 Jan 2017 18:58:22 +0200
> This series is intended to remove unneeded redundancies connected with
> common resource usage function.
>
> Since v1:
> - changed name to cpsw_get_usage_count()
> - added comments to open/closw for cpsw_get_usage_count()
> - added patch:
> net: ethernet: ti: cpsw: clarify ethtool ops changing num of descs
>
> Based on net-next/master
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH iproute2] ip route: error out on multiple via without nexthop keyword
From: Stephen Hemminger @ 2017-01-20 17:38 UTC (permalink / raw)
To: David Ahern; +Cc: netdev
In-Reply-To: <1484845701-19354-1-git-send-email-dsa@cumulusnetworks.com>
On Thu, 19 Jan 2017 09:08:21 -0800
David Ahern <dsa@cumulusnetworks.com> wrote:
> To specify multiple nexthops in a route the user is expected to use the
> "nexthop" keyword which ip route uses to create the RTA_MULTIPATH.
> However, ip route always accepts multiple 'via' keywords where only the
> last one is used in the route leading to confusion. For example, ip
> accepts this syntax:
> $ ip ro add vrf red 1.1.1.0/24 via 10.100.1.18 via 10.100.2.18
>
> but the route entered inserted by the kernel is just the last gateway:
> 1.1.1.0/24 via 10.100.2.18 dev eth2
>
> which is not the full request from the user. Detect the presense of
> multiple 'via' and give the user a hint to add nexthop:
>
> $ ip ro add vrf red 1.1.1.0/24 via 10.100.1.18 via 10.100.2.18
> Error: argument "via" is wrong: use nexthop syntax to specify multiple via
>
> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Applied thanks.
^ permalink raw reply
* Re: [PATCH iproute2] f_flower: don't set TCA_FLOWER_KEY_ETH_TYPE for "protocol all"
From: Stephen Hemminger @ 2017-01-20 17:34 UTC (permalink / raw)
To: Benjamin LaHaise; +Cc: netdev, bcrl
In-Reply-To: <20170119215159.GA32126@nvt-d.home.kvack.org>
On Thu, 19 Jan 2017 16:51:59 -0500
Benjamin LaHaise <benjamin.lahaise@netronome.com> wrote:
> When using the tc filter flower, rules marked with "protocol all" do not
> actually match all packets. This is due to a bug in f_flower.c that passes
> in ETH_P_ALL in the TCA_FLOWER_KEY_ETH_TYPE attribute when adding a rule.
> Fix this by omitting TCA_FLOWER_KEY_ETH_TYPE if the protocol is set to
> ETH_P_ALL.
>
> Signed-off-by: Benjamin LaHaise <benjamin.lahaise@netronome.com>
> Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
This looks good, but does not apply cleanly to either master or net-next branch
of current repository. Please rebase and resubmit.
It would be helpful to to use Fixes: tag for something which was broken by
a single previous commit.
^ permalink raw reply
* Re: [PATCH iproute2 net-next v2] ipmroute: add support for RTNH_F_UNRESOLVED
From: Stephen Hemminger @ 2017-01-20 17:42 UTC (permalink / raw)
To: Nikolay Aleksandrov; +Cc: netdev, roopa
In-Reply-To: <1484921721-24378-1-git-send-email-nikolay@cumulusnetworks.com>
On Fri, 20 Jan 2017 15:15:21 +0100
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> wrote:
> This patch adds a new field that is printed in the end of the line which
> denotes the real entry state. Before this patch an entry's IIF could
> disappear and it would look like an unresolved one (iif = unresolved):
> (3.0.16.1, 225.11.16.1) Iif: unresolved
> with no way to really distinguish it from an unresolved entry.
> After the patch if the dumped entry has RTNH_F_UNRESOLVED set we get:
> (3.0.16.1, 225.11.16.1) Iif: unresolved State: unresolved
> for unresolved entries and:
> (0.0.0.0, 225.11.11.11) Iif: eth4 Oifs: eth3 State: resolved
> for resolved entries after the OIF list. Note that "State:" has ':' in
> it so it cannot be mistaken for an interface name.
>
> And for the example above, we'd get:
> (0.0.0.0, 225.11.11.11) Iif: unresolved State: resolved
>
> Also when dumping all routes via ip route show table all, it will show
> up as:
> multicast 225.11.16.1/32 from 3.0.16.1/32 table default proto 17 unresolved
>
> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Applied to net-next
^ permalink raw reply
* Re: [PATCH net] net/mlx5e: Do not recycle pages from emergency reserve
From: David Miller @ 2017-01-20 17:43 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, tariqt, saeedm
In-Reply-To: <1484809388.16328.19.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 18 Jan 2017 23:03:08 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> A driver using dev_alloc_page() must not reuse a page allocated from
> emergency memory reserve.
>
> Otherwise all packets using this page will be immediately dropped,
> unless for very specific sockets having SOCK_MEMALLOC bit set.
>
> This issue might be hard to debug, because only a fraction of received
> packets would be dropped.
>
> Fixes: 4415a0319f92 ("net/mlx5e: Implement RX mapped page cache for page recycle")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH v5 0/2] Add support for the ethernet switch on the ESPRESSObin
From: Andrew Lunn @ 2017-01-20 17:43 UTC (permalink / raw)
To: Gregory CLEMENT
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: <87a8al64mp.fsf@free-electrons.com>
> 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.
Hi Gregory
Probably the best thing to do is wait until the temperature code moves
into the PHY driver. It then becomes easier to test. It probably is
the same as the 6352, or like the 6390 which i've so far failed to get
working, despite the registers being the same as the 6352.
Andrew
^ permalink raw reply
* Re: [net PATCH v5 6/6] virtio_net: XDP support for adjust_head
From: Michael S. Tsirkin @ 2017-01-20 17:48 UTC (permalink / raw)
To: David Laight
Cc: Jason Wang, John Fastabend, john.r.fastabend@intel.com,
netdev@vger.kernel.org, alexei.starovoitov@gmail.com,
daniel@iogearbox.net
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DB026921C@AcuExch.aculab.com>
On Fri, Jan 20, 2017 at 04:59:11PM +0000, David Laight wrote:
> 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
>
I like that. John?
--
MST
^ permalink raw reply
* [PATCHv4 net-next 0/5] sctp: add sender-side procedures for stream reconf asoc reset and add streams
From: Xin Long @ 2017-01-20 18:00 UTC (permalink / raw)
To: network dev, linux-sctp
Cc: Marcelo Ricardo Leitner, Neil Horman, Vlad Yasevich, davem
Patch 3/5 is to implement sender-side procedures for the SSN/TSN Reset
Request Parameter described in rfc6525 section 5.1.4, patch 2/5 is
ahead of it to define a function to make the request chunk for it.
Patch 5/5 is to implement sender-side procedures for the Add Incoming
and Outgoing Streams Request Parameter Request Parameter described in
rfc6525 section 5.1.5 and 5.1.6, patch 4/5 is ahead of it to define a
function to make the request chunk for it.
Patch 1/5 is a fix to make streams be closed only when request is sent
successfully.
v1->v2:
- put these into a smaller group.
- rename some temporary variables in the codes.
- rename the titles of the commits and improve some changelogs.
v2->v3:
- re-split the patchset and make sure it has no dead codes for review.
- move some codes into stream.c from socket.c.
v3->v4:
- add one more patch to fix a send reset stream request issue.
- doing actual work only when request is sent successfully.
- reduce some indents in sctp_send_add_streams.
Xin Long (5):
sctp: streams should be closed when stream reset request is sent
successfully.
sctp: add support for generating stream reconf ssn/tsn reset request
chunk
sctp: implement sender-side procedures for SSN/TSN Reset Request
Parameter
sctp: add support for generating stream reconf add incoming/outgoing
streams request chunk
sctp: implement sender-side procedures for Add Incoming/Outgoing
Streams Request Parameter
include/linux/sctp.h | 12 +++++
include/net/sctp/sctp.h | 3 ++
include/net/sctp/sm.h | 5 ++
include/uapi/linux/sctp.h | 8 +++
net/sctp/sm_make_chunk.c | 75 ++++++++++++++++++++++++++++
net/sctp/socket.c | 58 ++++++++++++++++++++++
net/sctp/stream.c | 124 +++++++++++++++++++++++++++++++++++++++++++++-
7 files changed, 284 insertions(+), 1 deletion(-)
--
2.1.0
^ 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