* [PATCH] netlink: Change rtnl_dump_done to always show error
From: David Ahern @ 2017-05-16 21:22 UTC (permalink / raw)
To: netdev, stephen; +Cc: David Ahern
The original code which became rtnl_dump_done only shows netlink errors
if the protocol is NETLINK_SOCK_DIAG, but netlink dumps always appends
the length which contains any error encountered during the dump. Update
rtnl_dump_done to always show the error if there is one.
As an *example* without this patch, dumping a route object that exceeds
the internal buffer size terminates with no message to the user -- the
dump just ends because the NLMSG_DONE attribute was received. With this
patch the user at least gets a message that the dump was aborted.
$ ip ro ls
default via 10.0.2.2 dev eth0
10.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.15
10.10.0.0/16 dev veth1 proto kernel scope link src 10.10.0.1
172.16.1.0/24 dev br0.11 proto kernel scope link src 172.16.1.1
Error: Buffer too small for object
Dump terminated
The point of this patch is to notify the user of a failure versus
silently exiting on a partial dump. Because the NLMSG_DONE attribute
was received, the entire dump needs to be restarted to use a larger
buffer for EMSGSIZE errors. That could be done automatically but it
has other user impacts (e.g., duplicate output if the dump is
restarted) and should be the subject of a different patch.
Signed-off-by: David Ahern <dsahern@gmail.com>
---
lib/libnetlink.c | 28 +++++++++++++++++-----------
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/lib/libnetlink.c b/lib/libnetlink.c
index 5b75b2db4e0b..d4b831f67ea2 100644
--- a/lib/libnetlink.c
+++ b/lib/libnetlink.c
@@ -266,21 +266,27 @@ static int rtnl_dump_done(const struct rtnl_handle *rth,
{
int len = *(int *)NLMSG_DATA(h);
- if (rth->proto == NETLINK_SOCK_DIAG) {
- if (h->nlmsg_len < NLMSG_LENGTH(sizeof(int))) {
- fprintf(stderr, "DONE truncated\n");
- return -1;
- }
-
+ if (h->nlmsg_len < NLMSG_LENGTH(sizeof(int))) {
+ fprintf(stderr, "DONE truncated\n");
+ return -1;
+ }
- if (len < 0) {
- errno = -len;
- if (errno == ENOENT || errno == EOPNOTSUPP)
- return -1;
+ if (len < 0) {
+ errno = -len;
+ switch (errno) {
+ case ENOENT:
+ case EOPNOTSUPP:
+ return -1;
+ case EMSGSIZE:
+ fprintf(stderr,
+ "Error: Buffer too small for object.\n");
+ break;
+ default:
perror("RTNETLINK answers");
- return len;
}
+ return len;
}
+
return 0;
}
--
2.11.0 (Apple Git-81)
^ permalink raw reply related
* Re: [PATCH net-next] net: dsa: store CPU port pointer in the tree
From: Florian Fainelli @ 2017-05-16 21:16 UTC (permalink / raw)
To: Vivien Didelot, netdev; +Cc: linux-kernel, kernel, David S. Miller, Andrew Lunn
In-Reply-To: <20170516181033.19980-1-vivien.didelot@savoirfairelinux.com>
On 05/16/2017 11:10 AM, Vivien Didelot wrote:
> A dsa_switch_tree instance holds a dsa_switch pointer and a port index
> to identify the switch port to which the CPU is attached.
>
> Now that the DSA layer has a dsa_port structure to hold this data, use
> it to point the switch CPU port.
>
> This patch simply substitutes s/dst->cpu_switch/dst->cpu_dp->ds/ and
> s/dst->cpu_port/dst->cpu_dp->index/.
>
> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
^ permalink raw reply
* Re: [PATCH net-next 0/2] net: dsa: Sort various lists
From: Vivien Didelot @ 2017-05-16 21:10 UTC (permalink / raw)
To: Andrew Lunn, David Miller; +Cc: netdev, Florian Fainelli, Andrew Lunn
In-Reply-To: <1494967208-11550-1-git-send-email-andrew@lunn.ch>
Hi Andrew,
Andrew Lunn <andrew@lunn.ch> writes:
> As we gain more DSA drivers and tagging protocols, the lists are
> getting a bit unruly. Do some sorting.
I'm glad to see that I'm not the only one picky with alphabetically
ordering (when possible) files, function names and so on.
Thanks!
Vivien
^ permalink raw reply
* Re: [PATCH net-next 2/2] drivers: net: DSA: Sort drivers
From: Florian Fainelli @ 2017-05-16 21:12 UTC (permalink / raw)
To: Andrew Lunn, David Miller; +Cc: netdev, Vivien Didelot
In-Reply-To: <1494967208-11550-3-git-send-email-andrew@lunn.ch>
On 05/16/2017 01:40 PM, Andrew Lunn wrote:
> With more drivers being added, it is time to sort the drivers to
> impose some order.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [PATCH net-next 2/2] drivers: net: DSA: Sort drivers
From: Vivien Didelot @ 2017-05-16 21:09 UTC (permalink / raw)
To: Andrew Lunn, David Miller; +Cc: netdev, Florian Fainelli, Andrew Lunn
In-Reply-To: <1494967208-11550-3-git-send-email-andrew@lunn.ch>
Andrew Lunn <andrew@lunn.ch> writes:
> With more drivers being added, it is time to sort the drivers to
> impose some order.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: dsa: Sort DSA tagging protocol drivers
From: Vivien Didelot @ 2017-05-16 21:09 UTC (permalink / raw)
To: Andrew Lunn, David Miller; +Cc: netdev, Florian Fainelli, Andrew Lunn
In-Reply-To: <1494967208-11550-2-git-send-email-andrew@lunn.ch>
Andrew Lunn <andrew@lunn.ch> writes:
> With more tag protocols being added, regain some order by sorting the
> entries in various places.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
^ permalink raw reply
* Re: [patch net-next v3 01/10] net: sched: move tc_classify function to cls_api.c
From: Jiri Pirko @ 2017-05-16 21:05 UTC (permalink / raw)
To: Cong Wang
Cc: Linux Kernel Network Developers, David Miller, Jamal Hadi Salim,
David Ahern, Eric Dumazet, Stephen Hemminger, Daniel Borkmann,
Alexander Duyck, Simon Horman, mlxsw
In-Reply-To: <CAM_iQpWgtqBYEPTcdKqx=52kpmLTUug173Zdq+7gS-pniswy_A@mail.gmail.com>
Tue, May 16, 2017 at 11:03:14PM CEST, xiyou.wangcong@gmail.com wrote:
>On Tue, May 16, 2017 at 2:00 PM, Jiri Pirko <jiri@resnulli.us> wrote:
>> Tue, May 16, 2017 at 10:25:35PM CEST, xiyou.wangcong@gmail.com wrote:
>>>On Tue, May 16, 2017 at 10:27 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>>>> From: Jiri Pirko <jiri@mellanox.com>
>>>>
>>>> Move tc_classify function to cls_api.c where it belongs, rename it to
>>>> fit the namespace.
>>>>
>>>
>>>It is not a pure move, you silently remove the CONFIG_NET_CLS_ACT
>>>macros in tc_classify(). Probably not buggy, just redundancy when
>>>actions are not compiled.
>>
>> Plese see include/net/pkt_cls.h in this patch.
>>
>> If CONFIG_NET_CLS_ACT is not defined, there is a stub there.
>
>I am sure it is not NET_CLS_ACT:
Oh, will fix this. Thanks.
>
>
>#ifdef CONFIG_NET_CLS
> void tcf_destroy_chain(struct tcf_proto __rcu **fl);
>+int tcf_classify(struct sk_buff *skb, const struct tcf_proto *tp,
>+ struct tcf_result *res, bool compat_mode);
>+
> #else
> static inline void tcf_destroy_chain(struct tcf_proto __rcu **fl)
> {
> }
>+
>+static inline int tcf_classify(struct sk_buff *skb, const struct tcf_proto *tp,
>+ struct tcf_result *res, bool compat_mode)
>+{
>+ return TC_ACT_UNSPEC;
>+}
> #endif
^ permalink raw reply
* Re: [patch net-next v3 05/10] net: sched: move TC_H_MAJ macro call into tcf_auto_prio
From: Jiri Pirko @ 2017-05-16 21:03 UTC (permalink / raw)
To: Cong Wang
Cc: Linux Kernel Network Developers, David Miller, Jamal Hadi Salim,
David Ahern, Eric Dumazet, Stephen Hemminger, Daniel Borkmann,
Alexander Duyck, Simon Horman, mlxsw
In-Reply-To: <CAM_iQpXUY03tfi1RHLx0EnT5ZP1xPNdo4xGmUUiSKvRtSg44vw@mail.gmail.com>
Tue, May 16, 2017 at 11:01:52PM CEST, xiyou.wangcong@gmail.com wrote:
>On Tue, May 16, 2017 at 10:27 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>> From: Jiri Pirko <jiri@mellanox.com>
>>
>> Call the helper from the function rather than to always adjust the
>> return value of the function.
>
>And rename the function name to reflect this change?
? What do you suggest?
^ permalink raw reply
* Re: [patch net-next v3 01/10] net: sched: move tc_classify function to cls_api.c
From: Cong Wang @ 2017-05-16 21:03 UTC (permalink / raw)
To: Jiri Pirko
Cc: Linux Kernel Network Developers, David Miller, Jamal Hadi Salim,
David Ahern, Eric Dumazet, Stephen Hemminger, Daniel Borkmann,
Alexander Duyck, Simon Horman, mlxsw
In-Reply-To: <20170516210038.GR1939@nanopsycho.orion>
On Tue, May 16, 2017 at 2:00 PM, Jiri Pirko <jiri@resnulli.us> wrote:
> Tue, May 16, 2017 at 10:25:35PM CEST, xiyou.wangcong@gmail.com wrote:
>>On Tue, May 16, 2017 at 10:27 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>>> From: Jiri Pirko <jiri@mellanox.com>
>>>
>>> Move tc_classify function to cls_api.c where it belongs, rename it to
>>> fit the namespace.
>>>
>>
>>It is not a pure move, you silently remove the CONFIG_NET_CLS_ACT
>>macros in tc_classify(). Probably not buggy, just redundancy when
>>actions are not compiled.
>
> Plese see include/net/pkt_cls.h in this patch.
>
> If CONFIG_NET_CLS_ACT is not defined, there is a stub there.
I am sure it is not NET_CLS_ACT:
#ifdef CONFIG_NET_CLS
void tcf_destroy_chain(struct tcf_proto __rcu **fl);
+int tcf_classify(struct sk_buff *skb, const struct tcf_proto *tp,
+ struct tcf_result *res, bool compat_mode);
+
#else
static inline void tcf_destroy_chain(struct tcf_proto __rcu **fl)
{
}
+
+static inline int tcf_classify(struct sk_buff *skb, const struct tcf_proto *tp,
+ struct tcf_result *res, bool compat_mode)
+{
+ return TC_ACT_UNSPEC;
+}
#endif
^ permalink raw reply
* Re: [patch net-next v3 05/10] net: sched: move TC_H_MAJ macro call into tcf_auto_prio
From: Cong Wang @ 2017-05-16 21:01 UTC (permalink / raw)
To: Jiri Pirko
Cc: Linux Kernel Network Developers, David Miller, Jamal Hadi Salim,
David Ahern, Eric Dumazet, Stephen Hemminger, Daniel Borkmann,
Alexander Duyck, Simon Horman, mlxsw
In-Reply-To: <20170516172802.1317-6-jiri@resnulli.us>
On Tue, May 16, 2017 at 10:27 AM, Jiri Pirko <jiri@resnulli.us> wrote:
> From: Jiri Pirko <jiri@mellanox.com>
>
> Call the helper from the function rather than to always adjust the
> return value of the function.
And rename the function name to reflect this change?
^ permalink raw reply
* Re: [patch net-next v3 01/10] net: sched: move tc_classify function to cls_api.c
From: Jiri Pirko @ 2017-05-16 21:00 UTC (permalink / raw)
To: Cong Wang
Cc: Linux Kernel Network Developers, David Miller, Jamal Hadi Salim,
David Ahern, Eric Dumazet, Stephen Hemminger, Daniel Borkmann,
Alexander Duyck, Simon Horman, mlxsw
In-Reply-To: <CAM_iQpVqRTcK0H3wSiUEOXSk+pWtriSLFy7jtN6d77wrTjqe3Q@mail.gmail.com>
Tue, May 16, 2017 at 10:25:35PM CEST, xiyou.wangcong@gmail.com wrote:
>On Tue, May 16, 2017 at 10:27 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>> From: Jiri Pirko <jiri@mellanox.com>
>>
>> Move tc_classify function to cls_api.c where it belongs, rename it to
>> fit the namespace.
>>
>
>It is not a pure move, you silently remove the CONFIG_NET_CLS_ACT
>macros in tc_classify(). Probably not buggy, just redundancy when
>actions are not compiled.
Plese see include/net/pkt_cls.h in this patch.
If CONFIG_NET_CLS_ACT is not defined, there is a stub there.
^ permalink raw reply
* Re: [patch net-next v3 02/10] net: sched: introduce tcf block infractructure
From: Jiri Pirko @ 2017-05-16 20:57 UTC (permalink / raw)
To: Cong Wang
Cc: Linux Kernel Network Developers, David Miller, Jamal Hadi Salim,
David Ahern, Eric Dumazet, Stephen Hemminger, Daniel Borkmann,
Alexander Duyck, Simon Horman, mlxsw
In-Reply-To: <CAM_iQpW1wsvyg_v2Vy9Bg33f5iT9_c8kNdgn+0CXkAbVCs8=ew@mail.gmail.com>
Tue, May 16, 2017 at 10:51:30PM CEST, xiyou.wangcong@gmail.com wrote:
>On Tue, May 16, 2017 at 10:27 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>> +int tcf_block_get(struct tcf_block **p_block,
>> + struct tcf_proto __rcu **p_filter_chain)
>> +{
>> + struct tcf_block *block = kzalloc(sizeof(*block), GFP_KERNEL);
>> +
>> + if (!block)
>> + return -ENOMEM;
>> + block->p_filter_chain = p_filter_chain;
>> + *p_block = block;
>> + return 0;
>> +}
>> +EXPORT_SYMBOL(tcf_block_get);
>
>
>XXX_get() is usually for refcnt'ing, here you only allocate
>a block, so please rename it to tcf_block_alloc().
I already replied to the same Jamal's comment.
>
>
>> +
>> +void tcf_block_put(struct tcf_block *block)
>> +{
>> + if (!block)
>> + return;
>> + tcf_destroy_chain(block->p_filter_chain);
>> + kfree(block);
>> +}
>> +EXPORT_SYMBOL(tcf_block_put);
>
>Ditto, tcf_block_destroy().
^ permalink raw reply
* Re: [patch net-next v3 02/10] net: sched: introduce tcf block infractructure
From: Cong Wang @ 2017-05-16 20:51 UTC (permalink / raw)
To: Jiri Pirko
Cc: Linux Kernel Network Developers, David Miller, Jamal Hadi Salim,
David Ahern, Eric Dumazet, Stephen Hemminger, Daniel Borkmann,
Alexander Duyck, Simon Horman, mlxsw
In-Reply-To: <20170516172802.1317-3-jiri@resnulli.us>
On Tue, May 16, 2017 at 10:27 AM, Jiri Pirko <jiri@resnulli.us> wrote:
> +int tcf_block_get(struct tcf_block **p_block,
> + struct tcf_proto __rcu **p_filter_chain)
> +{
> + struct tcf_block *block = kzalloc(sizeof(*block), GFP_KERNEL);
> +
> + if (!block)
> + return -ENOMEM;
> + block->p_filter_chain = p_filter_chain;
> + *p_block = block;
> + return 0;
> +}
> +EXPORT_SYMBOL(tcf_block_get);
XXX_get() is usually for refcnt'ing, here you only allocate
a block, so please rename it to tcf_block_alloc().
> +
> +void tcf_block_put(struct tcf_block *block)
> +{
> + if (!block)
> + return;
> + tcf_destroy_chain(block->p_filter_chain);
> + kfree(block);
> +}
> +EXPORT_SYMBOL(tcf_block_put);
Ditto, tcf_block_destroy().
^ permalink raw reply
* Re: [PATCH v2 net-next 06/12] ep93xx_eth: add GRO support
From: Eric Dumazet @ 2017-05-16 20:48 UTC (permalink / raw)
To: Alexander Sverdlin
Cc: Ryan Mallon, Lennert Buytenhek, David S. Miller, netdev,
Eric Dumazet, Hartley Sweeten
In-Reply-To: <8ce1ad39-5f57-ecff-805d-0aaca6fbd138@gmail.com>
On Tue, May 16, 2017 at 1:41 PM, Alexander Sverdlin
<alexander.sverdlin@gmail.com> wrote:
> it turns out I've used this patch two weeks long already in 4.11; but I've spent
> a couple of hours now torturing the new driver and was not able to provoke
> any inadequate behavior. It either receives all packets in time or not at all.
> If IRQs would be edge-triggered, I'd expect some stale packets, which do not
> arrive at first, but then appear with the packets coming next. This is not
> the case. I've used pktgen module for this, with minimal packets and
> different bursts.
>
> netperf shows 45Mbit/s on UDP_STREAM test, which is also fair amount for
> 200MHz CPU.
>
> So, I see no problems with the change.
>
Thanks a lot for testing !
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: store CPU port pointer in the tree
From: Andrew Lunn @ 2017-05-16 20:42 UTC (permalink / raw)
To: Vivien Didelot
Cc: netdev, linux-kernel, kernel, David S. Miller, Florian Fainelli
In-Reply-To: <20170516181033.19980-1-vivien.didelot@savoirfairelinux.com>
On Tue, May 16, 2017 at 02:10:33PM -0400, Vivien Didelot wrote:
> A dsa_switch_tree instance holds a dsa_switch pointer and a port index
> to identify the switch port to which the CPU is attached.
>
> Now that the DSA layer has a dsa_port structure to hold this data, use
> it to point the switch CPU port.
>
> This patch simply substitutes s/dst->cpu_switch/dst->cpu_dp->ds/ and
> s/dst->cpu_port/dst->cpu_dp->index/.
>
> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH net-next 1/2] net: dsa: Sort DSA tagging protocol drivers
From: Andrew Lunn @ 2017-05-16 20:40 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Florian Fainelli, Vivien Didelot, Andrew Lunn
In-Reply-To: <1494967208-11550-1-git-send-email-andrew@lunn.ch>
With more tag protocols being added, regain some order by sorting the
entries in various places.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
include/net/dsa.h | 8 ++++----
net/dsa/Kconfig | 8 ++++----
net/dsa/Makefile | 6 +++---
net/dsa/dsa.c | 18 +++++++++---------
net/dsa/dsa_priv.h | 18 +++++++++---------
5 files changed, 29 insertions(+), 29 deletions(-)
diff --git a/include/net/dsa.h b/include/net/dsa.h
index 8e24677b1c62..f5b3ab645624 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -27,13 +27,13 @@ struct fixed_phy_status;
enum dsa_tag_protocol {
DSA_TAG_PROTO_NONE = 0,
+ DSA_TAG_PROTO_BRCM,
DSA_TAG_PROTO_DSA,
- DSA_TAG_PROTO_TRAILER,
DSA_TAG_PROTO_EDSA,
- DSA_TAG_PROTO_BRCM,
- DSA_TAG_PROTO_QCA,
- DSA_TAG_PROTO_MTK,
DSA_TAG_PROTO_LAN9303,
+ DSA_TAG_PROTO_MTK,
+ DSA_TAG_PROTO_QCA,
+ DSA_TAG_PROTO_TRAILER,
DSA_TAG_LAST, /* MUST BE LAST */
};
diff --git a/net/dsa/Kconfig b/net/dsa/Kconfig
index 81a0868edb1d..297389b2ab35 100644
--- a/net/dsa/Kconfig
+++ b/net/dsa/Kconfig
@@ -25,16 +25,16 @@ config NET_DSA_TAG_DSA
config NET_DSA_TAG_EDSA
bool
-config NET_DSA_TAG_TRAILER
+config NET_DSA_TAG_LAN9303
bool
-config NET_DSA_TAG_QCA
+config NET_DSA_TAG_MTK
bool
-config NET_DSA_TAG_MTK
+config NET_DSA_TAG_TRAILER
bool
-config NET_DSA_TAG_LAN9303
+config NET_DSA_TAG_QCA
bool
endif
diff --git a/net/dsa/Makefile b/net/dsa/Makefile
index 0b747d75e65a..f8c0251d1f43 100644
--- a/net/dsa/Makefile
+++ b/net/dsa/Makefile
@@ -6,7 +6,7 @@ dsa_core-y += dsa.o slave.o dsa2.o switch.o legacy.o
dsa_core-$(CONFIG_NET_DSA_TAG_BRCM) += tag_brcm.o
dsa_core-$(CONFIG_NET_DSA_TAG_DSA) += tag_dsa.o
dsa_core-$(CONFIG_NET_DSA_TAG_EDSA) += tag_edsa.o
-dsa_core-$(CONFIG_NET_DSA_TAG_TRAILER) += tag_trailer.o
-dsa_core-$(CONFIG_NET_DSA_TAG_QCA) += tag_qca.o
-dsa_core-$(CONFIG_NET_DSA_TAG_MTK) += tag_mtk.o
dsa_core-$(CONFIG_NET_DSA_TAG_LAN9303) += tag_lan9303.o
+dsa_core-$(CONFIG_NET_DSA_TAG_MTK) += tag_mtk.o
+dsa_core-$(CONFIG_NET_DSA_TAG_QCA) += tag_qca.o
+dsa_core-$(CONFIG_NET_DSA_TAG_TRAILER) += tag_trailer.o
diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
index 26130ae438da..c0a1307c87dd 100644
--- a/net/dsa/dsa.c
+++ b/net/dsa/dsa.c
@@ -40,26 +40,26 @@ static const struct dsa_device_ops none_ops = {
};
const struct dsa_device_ops *dsa_device_ops[DSA_TAG_LAST] = {
+#ifdef CONFIG_NET_DSA_TAG_BRCM
+ [DSA_TAG_PROTO_BRCM] = &brcm_netdev_ops,
+#endif
#ifdef CONFIG_NET_DSA_TAG_DSA
[DSA_TAG_PROTO_DSA] = &dsa_netdev_ops,
#endif
#ifdef CONFIG_NET_DSA_TAG_EDSA
[DSA_TAG_PROTO_EDSA] = &edsa_netdev_ops,
#endif
-#ifdef CONFIG_NET_DSA_TAG_TRAILER
- [DSA_TAG_PROTO_TRAILER] = &trailer_netdev_ops,
+#ifdef CONFIG_NET_DSA_TAG_LAN9303
+ [DSA_TAG_PROTO_LAN9303] = &lan9303_netdev_ops,
#endif
-#ifdef CONFIG_NET_DSA_TAG_BRCM
- [DSA_TAG_PROTO_BRCM] = &brcm_netdev_ops,
+#ifdef CONFIG_NET_DSA_TAG_MTK
+ [DSA_TAG_PROTO_MTK] = &mtk_netdev_ops,
#endif
#ifdef CONFIG_NET_DSA_TAG_QCA
[DSA_TAG_PROTO_QCA] = &qca_netdev_ops,
#endif
-#ifdef CONFIG_NET_DSA_TAG_MTK
- [DSA_TAG_PROTO_MTK] = &mtk_netdev_ops,
-#endif
-#ifdef CONFIG_NET_DSA_TAG_LAN9303
- [DSA_TAG_PROTO_LAN9303] = &lan9303_netdev_ops,
+#ifdef CONFIG_NET_DSA_TAG_TRAILER
+ [DSA_TAG_PROTO_TRAILER] = &trailer_netdev_ops,
#endif
[DSA_TAG_PROTO_NONE] = &none_ops,
};
diff --git a/net/dsa/dsa_priv.h b/net/dsa/dsa_priv.h
index f4a88e485213..e9003b79cbbc 100644
--- a/net/dsa/dsa_priv.h
+++ b/net/dsa/dsa_priv.h
@@ -75,25 +75,25 @@ void dsa_slave_unregister_notifier(void);
int dsa_switch_register_notifier(struct dsa_switch *ds);
void dsa_switch_unregister_notifier(struct dsa_switch *ds);
+/* tag_brcm.c */
+extern const struct dsa_device_ops brcm_netdev_ops;
+
/* tag_dsa.c */
extern const struct dsa_device_ops dsa_netdev_ops;
/* tag_edsa.c */
extern const struct dsa_device_ops edsa_netdev_ops;
-/* tag_trailer.c */
-extern const struct dsa_device_ops trailer_netdev_ops;
+/* tag_lan9303.c */
+extern const struct dsa_device_ops lan9303_netdev_ops;
-/* tag_brcm.c */
-extern const struct dsa_device_ops brcm_netdev_ops;
+/* tag_mtk.c */
+extern const struct dsa_device_ops mtk_netdev_ops;
/* tag_qca.c */
extern const struct dsa_device_ops qca_netdev_ops;
-/* tag_mtk.c */
-extern const struct dsa_device_ops mtk_netdev_ops;
-
-/* tag_lan9303.c */
-extern const struct dsa_device_ops lan9303_netdev_ops;
+/* tag_trailer.c */
+extern const struct dsa_device_ops trailer_netdev_ops;
#endif
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v2 net-next 06/12] ep93xx_eth: add GRO support
From: Alexander Sverdlin @ 2017-05-16 20:41 UTC (permalink / raw)
To: Ryan Mallon, Lennert Buytenhek, Eric Dumazet
Cc: David S. Miller, netdev, Eric Dumazet, Hartley Sweeten
In-Reply-To: <1494882170.2185.2.camel@Nokia-N900>
Hello all,
On 15/05/17 23:02, Alexander Sverdlin wrote:
>>> I don't know if we really care about this hardware anymore (I don't),
>>> but the ep93xx platform is still listed as being maintained in the
>>> MAINTAINERS file -- adding Ryan and Hartley.
>> I no longer have any ep93xx hardware to test with, and I never looked at
>> the Ethernet, so don't know the details. I think there are still a
>> handful of users. Adding Alexander who sent an ADC support series this
>> week, who might be able to test this?
> Yes, I very much care about ep93xx code being functional :)
> I'll test the patches tomorrow.
it turns out I've used this patch two weeks long already in 4.11; but I've spent
a couple of hours now torturing the new driver and was not able to provoke
any inadequate behavior. It either receives all packets in time or not at all.
If IRQs would be edge-triggered, I'd expect some stale packets, which do not
arrive at first, but then appear with the packets coming next. This is not
the case. I've used pktgen module for this, with minimal packets and
different bursts.
netperf shows 45Mbit/s on UDP_STREAM test, which is also fair amount for
200MHz CPU.
So, I see no problems with the change.
^ permalink raw reply
* [PATCH net-next 0/2] net: dsa: Sort various lists
From: Andrew Lunn @ 2017-05-16 20:40 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Florian Fainelli, Vivien Didelot, Andrew Lunn
As we gain more DSA drivers and tagging protocols, the lists are
getting a bit unruly. Do some sorting.
Andrew Lunn (2):
net: dsa: Sort DSA tagging protocol drivers
drivers: net: DSA: Sort drivers
drivers/net/dsa/Kconfig | 40 ++++++++++++++++++++--------------------
drivers/net/dsa/Makefile | 6 +++---
include/net/dsa.h | 8 ++++----
net/dsa/Kconfig | 8 ++++----
net/dsa/Makefile | 6 +++---
net/dsa/dsa.c | 18 +++++++++---------
net/dsa/dsa_priv.h | 18 +++++++++---------
7 files changed, 52 insertions(+), 52 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH net-next 2/2] drivers: net: DSA: Sort drivers
From: Andrew Lunn @ 2017-05-16 20:40 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Florian Fainelli, Vivien Didelot, Andrew Lunn
In-Reply-To: <1494967208-11550-1-git-send-email-andrew@lunn.ch>
With more drivers being added, it is time to sort the drivers to
impose some order.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/dsa/Kconfig | 40 ++++++++++++++++++++--------------------
drivers/net/dsa/Makefile | 6 +++---
2 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/drivers/net/dsa/Kconfig b/drivers/net/dsa/Kconfig
index 862ee22303c2..68131a45ac5e 100644
--- a/drivers/net/dsa/Kconfig
+++ b/drivers/net/dsa/Kconfig
@@ -1,13 +1,7 @@
menu "Distributed Switch Architecture drivers"
depends on HAVE_NET_DSA
-config NET_DSA_MV88E6060
- tristate "Marvell 88E6060 ethernet switch chip support"
- depends on NET_DSA
- select NET_DSA_TAG_TRAILER
- ---help---
- This enables support for the Marvell 88E6060 ethernet switch
- chip.
+source "drivers/net/dsa/b53/Kconfig"
config NET_DSA_BCM_SF2
tristate "Broadcom Starfighter 2 Ethernet switch support"
@@ -21,19 +15,6 @@ config NET_DSA_BCM_SF2
This enables support for the Broadcom Starfighter 2 Ethernet
switch chips.
-source "drivers/net/dsa/b53/Kconfig"
-
-source "drivers/net/dsa/mv88e6xxx/Kconfig"
-
-config NET_DSA_QCA8K
- tristate "Qualcomm Atheros QCA8K Ethernet switch family support"
- depends on NET_DSA
- select NET_DSA_TAG_QCA
- select REGMAP
- ---help---
- This enables support for the Qualcomm Atheros QCA8K Ethernet
- switch chips.
-
config NET_DSA_LOOP
tristate "DSA mock-up Ethernet switch chip support"
depends on NET_DSA
@@ -50,6 +31,25 @@ config NET_DSA_MT7530
This enables support for the Mediatek MT7530 Ethernet switch
chip.
+config NET_DSA_MV88E6060
+ tristate "Marvell 88E6060 ethernet switch chip support"
+ depends on NET_DSA
+ select NET_DSA_TAG_TRAILER
+ ---help---
+ This enables support for the Marvell 88E6060 ethernet switch
+ chip.
+
+source "drivers/net/dsa/mv88e6xxx/Kconfig"
+
+config NET_DSA_QCA8K
+ tristate "Qualcomm Atheros QCA8K Ethernet switch family support"
+ depends on NET_DSA
+ select NET_DSA_TAG_QCA
+ select REGMAP
+ ---help---
+ This enables support for the Qualcomm Atheros QCA8K Ethernet
+ switch chips.
+
config NET_DSA_SMSC_LAN9303
tristate
select NET_DSA_TAG_LAN9303
diff --git a/drivers/net/dsa/Makefile b/drivers/net/dsa/Makefile
index edd630361736..9613f36083a6 100644
--- a/drivers/net/dsa/Makefile
+++ b/drivers/net/dsa/Makefile
@@ -1,11 +1,11 @@
-obj-$(CONFIG_NET_DSA_MV88E6060) += mv88e6060.o
obj-$(CONFIG_NET_DSA_BCM_SF2) += bcm-sf2.o
bcm-sf2-objs := bcm_sf2.o bcm_sf2_cfp.o
-obj-$(CONFIG_NET_DSA_QCA8K) += qca8k.o
+obj-$(CONFIG_NET_DSA_LOOP) += dsa_loop.o dsa_loop_bdinfo.o
obj-$(CONFIG_NET_DSA_MT7530) += mt7530.o
+obj-$(CONFIG_NET_DSA_MV88E6060) += mv88e6060.o
+obj-$(CONFIG_NET_DSA_QCA8K) += qca8k.o
obj-$(CONFIG_NET_DSA_SMSC_LAN9303) += lan9303-core.o
obj-$(CONFIG_NET_DSA_SMSC_LAN9303_I2C) += lan9303_i2c.o
obj-$(CONFIG_NET_DSA_SMSC_LAN9303_MDIO) += lan9303_mdio.o
obj-y += b53/
obj-y += mv88e6xxx/
-obj-$(CONFIG_NET_DSA_LOOP) += dsa_loop.o dsa_loop_bdinfo.o
--
2.11.0
^ permalink raw reply related
* [PATCH net 2/2] bnxt_en: Check status of firmware DCBX agent before setting DCB_CAP_DCBX_HOST.
From: Michael Chan @ 2017-05-16 20:39 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1494967184-12865-1-git-send-email-michael.chan@broadcom.com>
Otherwise, all the host based DCBX settings from lldpad will fail if the
firmware DCBX agent is running.
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.c
index 46de2f8..5c6dd0c 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.c
@@ -553,8 +553,10 @@ static u8 bnxt_dcbnl_setdcbx(struct net_device *dev, u8 mode)
if ((mode & DCB_CAP_DCBX_VER_CEE) || !(mode & DCB_CAP_DCBX_VER_IEEE))
return 1;
- if ((mode & DCB_CAP_DCBX_HOST) && BNXT_VF(bp))
- return 1;
+ if (mode & DCB_CAP_DCBX_HOST) {
+ if (BNXT_VF(bp) || (bp->flags & BNXT_FLAG_FW_LLDP_AGENT))
+ return 1;
+ }
if (mode == bp->dcbx_cap)
return 0;
--
1.8.3.1
^ permalink raw reply related
* [PATCH net 1/2] bnxt_en: Call bnxt_dcb_init() after getting firmware DCBX configuration.
From: Michael Chan @ 2017-05-16 20:39 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <1494967184-12865-1-git-send-email-michael.chan@broadcom.com>
In the current code, bnxt_dcb_init() is called too early before we
determine if the firmware DCBX agent is running or not. As a result,
we are not setting the DCB_CAP_DCBX_HOST and DCB_CAP_DCBX_LLD_MANAGED
flags properly to report to DCBNL.
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index b56c54d..03f55da 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -7630,8 +7630,6 @@ static int bnxt_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
dev->min_mtu = ETH_ZLEN;
dev->max_mtu = BNXT_MAX_MTU;
- bnxt_dcb_init(bp);
-
#ifdef CONFIG_BNXT_SRIOV
init_waitqueue_head(&bp->sriov_cfg_wait);
#endif
@@ -7669,6 +7667,7 @@ static int bnxt_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
bnxt_hwrm_func_qcfg(bp);
bnxt_hwrm_port_led_qcaps(bp);
bnxt_ethtool_init(bp);
+ bnxt_dcb_init(bp);
bnxt_set_rx_skb_mode(bp, false);
bnxt_set_tpa_flags(bp);
--
1.8.3.1
^ permalink raw reply related
* [PATCH net 0/2] bnxt_en: DCBX fixes.
From: Michael Chan @ 2017-05-16 20:39 UTC (permalink / raw)
To: davem; +Cc: netdev
2 bug fixes for the case where the NIC's firmware DCBX agent is enabled.
With these fixes, we will return the proper information to lldpad.
Michael Chan (2):
bnxt_en: Call bnxt_dcb_init() after getting firmware DCBX
configuration.
bnxt_en: Check status of firmware DCBX agent before setting
DCB_CAP_DCBX_HOST.
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 3 +--
drivers/net/ethernet/broadcom/bnxt/bnxt_dcb.c | 6 ++++--
2 files changed, 5 insertions(+), 4 deletions(-)
--
1.8.3.1
^ permalink raw reply
* [PATCH net] net: fix compile error in skb_orphan_partial()
From: Eric Dumazet @ 2017-05-16 20:27 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: Randy Dunlap, Stephen Rothwell, netdev@vger.kernel.org
In-Reply-To: <CAP=VYLoYkz1HE4yOHVGQvBanDtpkWhtHBMvbeuyd8PtNFCivRQ@mail.gmail.com>
From: Eric Dumazet <edumazet@google.com>
If CONFIG_INET is not set, net/core/sock.c can not compile :
net/core/sock.c: In function ‘skb_orphan_partial’:
net/core/sock.c:1810:2: error: implicit declaration of function
‘skb_is_tcp_pure_ack’ [-Werror=implicit-function-declaration]
if (skb_is_tcp_pure_ack(skb))
^
Fix this by always including <net/tcp.h>
Fixes: f6ba8d33cfbb ("netem: fix skb_orphan_partial()")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
net/core/sock.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/net/core/sock.c b/net/core/sock.c
index e43e71d7856b385111cd4c4b1bd835a78c670c60..727f924b7f91f495d9e7a4e7297c9c937d3258ed 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -139,10 +139,7 @@
#include <trace/events/sock.h>
-#ifdef CONFIG_INET
#include <net/tcp.h>
-#endif
-
#include <net/busy_poll.h>
static DEFINE_MUTEX(proto_list_mutex);
^ permalink raw reply related
* Re: [patch net-next v3 01/10] net: sched: move tc_classify function to cls_api.c
From: Cong Wang @ 2017-05-16 20:25 UTC (permalink / raw)
To: Jiri Pirko
Cc: Linux Kernel Network Developers, David Miller, Jamal Hadi Salim,
David Ahern, Eric Dumazet, Stephen Hemminger, Daniel Borkmann,
Alexander Duyck, Simon Horman, mlxsw
In-Reply-To: <20170516172802.1317-2-jiri@resnulli.us>
On Tue, May 16, 2017 at 10:27 AM, Jiri Pirko <jiri@resnulli.us> wrote:
> From: Jiri Pirko <jiri@mellanox.com>
>
> Move tc_classify function to cls_api.c where it belongs, rename it to
> fit the namespace.
>
It is not a pure move, you silently remove the CONFIG_NET_CLS_ACT
macros in tc_classify(). Probably not buggy, just redundancy when
actions are not compiled.
^ permalink raw reply
* Re: switchdev offload & ecmp
From: Nicolas Dichtel @ 2017-05-16 20:22 UTC (permalink / raw)
To: Ido Schimmel; +Cc: Jiri Pirko, Nikolay Aleksandrov, Roopa Prabhu, netdev
In-Reply-To: <20170516141149.GA1874@splinter.mtl.com>
Le 16/05/2017 à 16:11, Ido Schimmel a écrit :
> On Tue, May 16, 2017 at 02:57:47PM +0200, Nicolas Dichtel wrote:
>>>> I suspect that there can be scenarii where some packets of a flow are forwarded
>>>> by the driver and some other are forwarded by the kernel.
>>>
>>> Can you elaborate? The kernel only sees specific packets, which were
>>> trapped to the CPU. See:
>>> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/tree/drivers/net/ethernet/mellanox/mlxsw/spectrum.c#n2996
>> Ok, this part was not clear for me, thank you for the pointer.
>>
>> So, when an arp resolution is needed, the packets are not trapped to the CPU,
>> the device manages the queue itself?
>
> There are two cases here. If you need an ARP resolution following a hit
> of a directly connected route and this neighbour isn't in the device's
> table, then packet is trapped (HOST_MISS_IPV4 in above list) to the CPU
> and triggers ARP resolution in the kernel. Eventually a NETEVENT will be
> sent and the neighbour will be programmed to the device.
>
> If you need an ARP resolution of a nexthop, then this is a bit
> different. If you have an ECMP group with several nexthops, then once
> one of them is resolved, packets will be forwarded using it. To make
> sure other nexthops will also be resolved we try to periodically refresh
> them. Otherwise packets will always be forwarded using a single nexthop,
> as the kernel won't have motivation to resolve the others.
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c#n987
>
> In case no nexthops can be resolved, then packets will be trapped to the
> CPU (RTR_INGRESS0 in above list) and forwarded by the kernel.
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c#n1896
>
Ok, thank you for the details.
Regards,
Nicolas
^ 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