* Re: [PATCH net-next v2 1/5] net: Introduce NETIF_F_GRO_HW.
From: Michael Chan @ 2017-12-07 22:08 UTC (permalink / raw)
To: Alexander Duyck
Cc: David Miller, Netdev, Andrew Gospodarek, Ariel Elior,
everest-linux-l2
In-Reply-To: <CAKgT0Ue9h8Pdb4OkBiWdL5bSNHPUkbZfBosrtZ4gQOAnuGiwRQ@mail.gmail.com>
On Thu, Dec 7, 2017 at 1:35 PM, Alexander Duyck
<alexander.duyck@gmail.com> wrote:
> On Thu, Dec 7, 2017 at 10:44 AM, Michael Chan <michael.chan@broadcom.com> wrote:
>> On Thu, Dec 7, 2017 at 10:13 AM, Alexander Duyck
>> <alexander.duyck@gmail.com> wrote:
>>> On Thu, Dec 7, 2017 at 12:03 AM, Michael Chan <michael.chan@broadcom.com> wrote:
>>>> @@ -7405,6 +7405,23 @@ static netdev_features_t netdev_fix_features(struct net_device *dev,
>>>> features &= ~dev->gso_partial_features;
>>>> }
>>>>
>>>> + if (features & NETIF_F_GRO_HW) {
>>>> + /* Hardware GRO depends on GRO and RXCSUM. */
>>>> + if (!(features & NETIF_F_GRO)) {
>>>> + netdev_dbg(dev, "Dropping NETIF_F_GSO_HW since no GRO feature.\n");
>>>> + features &= ~NETIF_F_GRO_HW;
>>>> + }
>>>
>>> I'm not sure I agree with this part. The hardware offload should not
>>> be dependent on the software offload.
>>
>> As I said before, GRO_HW is basically hardware accelerated GRO. To me,
>> it makes perfect sense that GRO_HW depends on GRO.
>>
>>> If you are concerned with the
>>> XDP case and such you should probably just look at handling it more
>>> like how TSO is handled with a group of flags that aggregate GRO, LRO,
>>> and GRO_HW into a group of features that must be disabled to support
>>> XDP.
>>>
>>>> + if (!(features & NETIF_F_RXCSUM)) {
>>>> + netdev_dbg(dev, "Dropping NETIF_F_GSO_HW since no RXCSUM feature.\n");
>>>> + features &= ~NETIF_F_GRO_HW;
>>>> + }
>>>> + /* Hardware GRO and LRO are mutually exclusive. */
>>>> + if (features & NETIF_F_LRO) {
>>>> + netdev_dbg(dev, "Dropping NETIF_F_LRO since GRO_HW is set.\n");
>>>> + features &= ~NETIF_F_LRO;
>>>> + }
>>>
>>> This is going to be problematic. What if you bond one interface that
>>> has LRO and one that has GRO_HW? It seems like this is going to cause
>>> the bond interface to lie and say LRO isn't there when it actually is,
>>> or worse yet it will force features off when they shouldn't be.
>>
>> This is just dropping incompatible features similar to how other
>> incompatible feature flags are dropped in netdev_fix_features().
>> Hardware cannot aggregate in both LRO and GRO_HW modes at the same
>> time. It's one or the other.
>
> I'm not saying this is on a single device. The problem is in the case
> of bonding you have combined 2 devices. We don't want to have an upper
> device saying LRO isn't there when it is. A bonding setup is supposed
> to advertise LRO as being enabled if a lower device has it present.
> You are now making this an either/or thing at the driver level
> generically when that isn't the case due to things like bridging and
> bonding. This is why I was arguing that it would be easier to just
> make this a super-set of LRO with one form that is reversible and one
> that isn't. As is you are introducing all sorts of regressions that
> are going to be problematic in any sort of mixed environment.
Are you saying that if LRO is dropped on a upper device (by the new
code added in this patch), all lower devices will need to drop it too?
If that's what you are saying, it's already taken care of. There is
netdev_sync_upper_features() and netdev_sync_lower_features() that
will automatically do that as part of __netdev_update_features().
>
>> LRO and GRO_HW are different. We may never agree on this but they are
>> different. If a bond needs to disable LRO, it will be propagated to
>> all slaves. But each slave can have GRO enabled. If GRO is enabled,
>> GRO_HW, being a subset of GRO, can be enabled.
>
> I get that they are very different. At a driver level it makes sense
> to say you get one or the other at a physical driver level. The point
> I was trying to make is that the bond is only able to set one or the
> other when you might have a mix of devices. On the bonding device you
> should be able to have both LRO and GRO_HW enabled.
On the bond, you can have LRO enabled and it is propagated to lower
devices so that lower devices will enable LRO if it is supported. If
LRO is disabled on the bond (e.g. due to bridging), It will be
propagated so all lower devices will disable LRO if it is enabled.
GRO/GRO_HW is different and it is not propagated from upper devices to
lower devices like LRO. Lower devices can have GRO/GRO_HW
enabled/disabled regardless of upper device. This is no different
from say RXCSUM. Lower devices can have RXCSUM on/off regardless.
^ permalink raw reply
* Re: [PATCH net-next V3] tun: add eBPF based queue selection method
From: Eric Dumazet @ 2017-12-07 22:11 UTC (permalink / raw)
To: Jason Wang, netdev, linux-kernel
Cc: mst, willemdebruijn.kernel, tom, aconole, wexu
In-Reply-To: <1512379883-11887-1-git-send-email-jasowang@redhat.com>
On Mon, 2017-12-04 at 17:31 +0800, Jason Wang wrote:
> This patch introduces an eBPF based queue selection method. With
> this,
> the policy could be offloaded to userspace completely through a new
> ioctl TUNSETSTEERINGEBPF.
Sorry for the delay, I see this patch was merged already.
...
> static void tun_free_netdev(struct net_device *dev)
> {
> struct tun_struct *tun = netdev_priv(dev);
> @@ -1996,6 +2068,9 @@ static void tun_free_netdev(struct net_device
> *dev)
> free_percpu(tun->pcpu_stats);
> tun_flow_uninit(tun);
> security_tun_dev_free_security(tun->security);
> + rtnl_lock();
> + __tun_set_steering_ebpf(tun, NULL);
> + rtnl_unlock();
> }
I am pretty sure tun_free_netdev() (aka ->priv_destructor()) can be
called under RTNL (say from register_netdevice())
So this will dead lock badly ?
^ permalink raw reply
* Re: [Intel-wired-lan] [next-queue 06/10] ixgbe: restore offloaded SAs after a reset
From: Shannon Nelson @ 2017-12-07 22:19 UTC (permalink / raw)
To: Alexander Duyck
Cc: intel-wired-lan, Jeff Kirsher, Steffen Klassert, Sowmini Varadhan,
Netdev
In-Reply-To: <CAKgT0UfDnHnPCM8Px-TCbiB4wBQGN9CskftyF+4V=5g2F72QVw@mail.gmail.com>
On 12/7/2017 1:52 PM, Alexander Duyck wrote:
>
> The reads/writes themselves should be cheap. These kind of things only
> get to be really expensive when you start looking at adding delays in
> between the writes/reads polling on things. As long as we aren't
> waiting milliseconds on things you can write/read thousands of
> registers and not even notice it.
>
> One thing you might look at doing in order to speed some of this up a
> bit would be to also combine updating the Tx SA and Rx SA in your
> clear_hw_tables loop so that you could do them in parallel in your
> loop instead of having to do them in series. Anyway it is just a
> thought. If nothing else you might look at timing the function to see
> how long it actually takes. I suspect it shouldn't be too long since
> the turnaround time on the PCIe bus should be in microseconds so odds
> are reading/writing 35K registers might ovinly add a few milliseconds
> to total reset time.
>
Good ideas - thanks,
sln
^ permalink raw reply
* Re: [PATCH v2 net-next 4/4] bpftool: implement cgroup bpf operations
From: Jakub Kicinski @ 2017-12-07 22:23 UTC (permalink / raw)
To: Roman Gushchin
Cc: netdev, linux-kernel, kernel-team, ast, daniel, kafai,
Quentin Monnet, David Ahern
In-Reply-To: <20171207183909.16240-5-guro@fb.com>
On Thu, 7 Dec 2017 18:39:09 +0000, Roman Gushchin wrote:
> This patch adds basic cgroup bpf operations to bpftool:
> cgroup list, attach and detach commands.
>
> Usage is described in the corresponding man pages,
> and examples are provided.
>
> Syntax:
> $ bpftool cgroup list CGROUP
> $ bpftool cgroup attach CGROUP ATTACH_TYPE PROG [ATTACH_FLAGS]
> $ bpftool cgroup detach CGROUP ATTACH_TYPE PROG
>
> Signed-off-by: Roman Gushchin <guro@fb.com>
Looks good, a few very minor nits/questions below.
> diff --git a/tools/bpf/bpftool/cgroup.c b/tools/bpf/bpftool/cgroup.c
> new file mode 100644
> index 000000000000..88d67f74313f
> --- /dev/null
> +++ b/tools/bpf/bpftool/cgroup.c
> @@ -0,0 +1,305 @@
> +/*
> + * Copyright (C) 2017 Facebook
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + *
> + * Author: Roman Gushchin <guro@fb.com>
> + */
> +
> +#include <fcntl.h>
> +#include <stdlib.h>
> +#include <string.h>
> +#include <sys/stat.h>
> +#include <sys/types.h>
> +#include <unistd.h>
> +
> +#include <bpf.h>
> +
> +#include "main.h"
> +
> +static const char * const attach_type_strings[] = {
> + [BPF_CGROUP_INET_INGRESS] = "ingress",
> + [BPF_CGROUP_INET_EGRESS] = "egress",
> + [BPF_CGROUP_INET_SOCK_CREATE] = "sock_create",
> + [BPF_CGROUP_SOCK_OPS] = "sock_ops",
> + [BPF_CGROUP_DEVICE] = "device",
> + [__MAX_BPF_ATTACH_TYPE] = NULL,
> +};
> +
> +static enum bpf_attach_type parse_attach_type(const char *str)
> +{
> + enum bpf_attach_type type;
> +
> + for (type = 0; type < __MAX_BPF_ATTACH_TYPE; type++) {
> + if (attach_type_strings[type] &&
> + strcmp(str, attach_type_strings[type]) == 0)
Here and for matching flags you use straight strcmp(), not our locally
defined is_prefix(), is this intentional? is_prefix() allows
abbreviations, like in iproute2 commands. E.g. this would work:
# bpftool cg att /sys/fs/cgroup/test.slice/ dev id 1 allow_multi
> + return type;
> + }
> +
> + return __MAX_BPF_ATTACH_TYPE;
> +}
> +static int list_attached_bpf_progs(int cgroup_fd, enum bpf_attach_type type)
> +{
> + __u32 attach_flags;
> + __u32 prog_ids[1024] = {0};
> + __u32 prog_cnt, iter;
> + char *attach_flags_str;
> + int ret;
nit: could you reorder the variables so they're listed longest to
shortest (reverse christmas tree)?
> + prog_cnt = ARRAY_SIZE(prog_ids);
> + ret = bpf_prog_query(cgroup_fd, type, 0, &attach_flags, prog_ids,
> + &prog_cnt);
> + if (ret)
> + return ret;
> +
> + if (prog_cnt == 0)
> + return 0;
> +
> + switch (attach_flags) {
> + case BPF_F_ALLOW_MULTI:
> + attach_flags_str = "allow_multi";
> + break;
> + case BPF_F_ALLOW_OVERRIDE:
> + attach_flags_str = "allow_override";
> + break;
> + case 0:
> + attach_flags_str = "";
> + break;
> + default:
> + attach_flags_str = "unknown";
nit: would it make sense to perhaps print flags in hex format in this
case?
> + }
> +
> + for (iter = 0; iter < prog_cnt; iter++)
> + list_bpf_prog(prog_ids[iter], attach_type_strings[type],
> + attach_flags_str);
> +
> + return 0;
> +}
> +static int do_attach(int argc, char **argv)
> +{
> + int cgroup_fd, prog_fd;
> + enum bpf_attach_type attach_type;
> + int attach_flags = 0;
> + int i;
> + int ret = -1;
> +
> + if (argc < 4) {
> + p_err("too few parameters for cgroup attach\n");
> + goto exit;
> + }
> +
> + cgroup_fd = open(argv[0], O_RDONLY);
> + if (cgroup_fd < 0) {
> + p_err("can't open cgroup %s\n", argv[1]);
> + goto exit;
> + }
> +
> + attach_type = parse_attach_type(argv[1]);
> + if (attach_type == __MAX_BPF_ATTACH_TYPE) {
> + p_err("invalid attach type\n");
> + goto exit_cgroup;
> + }
> +
> + argc -= 2;
> + argv = &argv[2];
> + prog_fd = prog_parse_fd(&argc, &argv);
> + if (prog_fd < 0)
> + goto exit_cgroup;
> +
> + for (i = 0; i < argc; i++) {
> + if (strcmp(argv[i], "allow_multi") == 0) {
> + attach_flags |= BPF_F_ALLOW_MULTI;
> + } else if (strcmp(argv[i], "allow_override") == 0) {
> + attach_flags |= BPF_F_ALLOW_OVERRIDE;
This is the other potential place for is_prefix() I referred to.
That reminds me - would you care to also update Quentin's bash
completions (tools/bpf/bpftool/bash-completion/bpftool)? They
are _very_ nice to have in day to day use!
> + } else {
> + p_err("unknown option: %s\n", argv[i]);
> + goto exit_cgroup;
> + }
> + }
> +
> + if (bpf_prog_attach(prog_fd, cgroup_fd, attach_type, attach_flags)) {
> + p_err("failed to attach program");
> + goto exit_prog;
> + }
> +
> + if (json_output)
> + jsonw_null(json_wtr);
> +
> + ret = 0;
> +
> +exit_prog:
> + close(prog_fd);
> +exit_cgroup:
> + close(cgroup_fd);
> +exit:
> + return ret;
> +}
Otherwise looks really nice, thanks for working on it!
^ permalink raw reply
* Re: [PATCH] netfilter: fix clusterip_net_exit build regression
From: Pablo Neira Ayuso @ 2017-12-07 22:23 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Jozsef Kadlecsik, Florian Westphal, David S. Miller,
Alexey Kuznetsov, Hideaki YOSHIFUJI, Xin Long, Vasily Averin,
netfilter-devel, coreteam, netdev, linux-kernel
In-Reply-To: <20171207132636.259066-1-arnd@arndb.de>
On Thu, Dec 07, 2017 at 02:26:09PM +0100, Arnd Bergmann wrote:
> The added check produces a build error when CONFIG_PROC_FS is
> disabled:
>
> net/ipv4/netfilter/ipt_CLUSTERIP.c: In function 'clusterip_net_exit':
> net/ipv4/netfilter/ipt_CLUSTERIP.c:822:28: error: 'cn' undeclared (first use in this function)
>
> This moves the variable declaration out of the #ifdef to make it
> available to the WARN_ON_ONCE().
Applied, thanks Arnd.
^ permalink raw reply
* [PATCH] net: intel: e100: Fix warning of passing zero to 'PTR_ERR'
From: Vasyl Gomonovych @ 2017-12-07 22:39 UTC (permalink / raw)
To: jeffrey.t.kirsher, intel-wired-lan, gomonovych; +Cc: netdev, linux-kernel
fw could be NULL and put into PTR_ERR
also zero in PTR_ERR will be translated into success return statement
Signed-off-by: Vasyl Gomonovych <gomonovych@gmail.com>
---
drivers/net/ethernet/intel/e100.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/e100.c b/drivers/net/ethernet/intel/e100.c
index 4d10270..55e399d 100644
--- a/drivers/net/ethernet/intel/e100.c
+++ b/drivers/net/ethernet/intel/e100.c
@@ -1370,7 +1370,9 @@ static inline int e100_load_ucode_wait(struct nic *nic)
fw = e100_request_firmware(nic);
/* If it's NULL, then no ucode is required */
- if (!fw || IS_ERR(fw))
+ if (!fw)
+ return -EINVAL;
+ else if (IS_ERR(fw))
return PTR_ERR(fw);
if ((err = e100_exec_cb(nic, (void *)fw, e100_setup_ucode)))
--
1.9.1
^ permalink raw reply related
* Re: [PATCH net-next v2 1/5] net: Introduce NETIF_F_GRO_HW.
From: Alexander Duyck @ 2017-12-07 22:43 UTC (permalink / raw)
To: Michael Chan
Cc: David Miller, Netdev, Andrew Gospodarek, Ariel Elior,
everest-linux-l2
In-Reply-To: <CACKFLimOTo9ZQG1uQDgAKjxBX_YkpKp5D1c0j=pfCS09MoPYMg@mail.gmail.com>
On Thu, Dec 7, 2017 at 2:08 PM, Michael Chan <michael.chan@broadcom.com> wrote:
> On Thu, Dec 7, 2017 at 1:35 PM, Alexander Duyck
> <alexander.duyck@gmail.com> wrote:
>> On Thu, Dec 7, 2017 at 10:44 AM, Michael Chan <michael.chan@broadcom.com> wrote:
>>> On Thu, Dec 7, 2017 at 10:13 AM, Alexander Duyck
>>> <alexander.duyck@gmail.com> wrote:
>>>> On Thu, Dec 7, 2017 at 12:03 AM, Michael Chan <michael.chan@broadcom.com> wrote:
>>>>> @@ -7405,6 +7405,23 @@ static netdev_features_t netdev_fix_features(struct net_device *dev,
>>>>> features &= ~dev->gso_partial_features;
>>>>> }
>>>>>
>>>>> + if (features & NETIF_F_GRO_HW) {
>>>>> + /* Hardware GRO depends on GRO and RXCSUM. */
>>>>> + if (!(features & NETIF_F_GRO)) {
>>>>> + netdev_dbg(dev, "Dropping NETIF_F_GSO_HW since no GRO feature.\n");
>>>>> + features &= ~NETIF_F_GRO_HW;
>>>>> + }
>>>>
>>>> I'm not sure I agree with this part. The hardware offload should not
>>>> be dependent on the software offload.
>>>
>>> As I said before, GRO_HW is basically hardware accelerated GRO. To me,
>>> it makes perfect sense that GRO_HW depends on GRO.
>>>
>>>> If you are concerned with the
>>>> XDP case and such you should probably just look at handling it more
>>>> like how TSO is handled with a group of flags that aggregate GRO, LRO,
>>>> and GRO_HW into a group of features that must be disabled to support
>>>> XDP.
>>>>
>>>>> + if (!(features & NETIF_F_RXCSUM)) {
>>>>> + netdev_dbg(dev, "Dropping NETIF_F_GSO_HW since no RXCSUM feature.\n");
>>>>> + features &= ~NETIF_F_GRO_HW;
>>>>> + }
>>>>> + /* Hardware GRO and LRO are mutually exclusive. */
>>>>> + if (features & NETIF_F_LRO) {
>>>>> + netdev_dbg(dev, "Dropping NETIF_F_LRO since GRO_HW is set.\n");
>>>>> + features &= ~NETIF_F_LRO;
>>>>> + }
>>>>
>>>> This is going to be problematic. What if you bond one interface that
>>>> has LRO and one that has GRO_HW? It seems like this is going to cause
>>>> the bond interface to lie and say LRO isn't there when it actually is,
>>>> or worse yet it will force features off when they shouldn't be.
>>>
>>> This is just dropping incompatible features similar to how other
>>> incompatible feature flags are dropped in netdev_fix_features().
>>> Hardware cannot aggregate in both LRO and GRO_HW modes at the same
>>> time. It's one or the other.
>>
>> I'm not saying this is on a single device. The problem is in the case
>> of bonding you have combined 2 devices. We don't want to have an upper
>> device saying LRO isn't there when it is. A bonding setup is supposed
>> to advertise LRO as being enabled if a lower device has it present.
>> You are now making this an either/or thing at the driver level
>> generically when that isn't the case due to things like bridging and
>> bonding. This is why I was arguing that it would be easier to just
>> make this a super-set of LRO with one form that is reversible and one
>> that isn't. As is you are introducing all sorts of regressions that
>> are going to be problematic in any sort of mixed environment.
>
> Are you saying that if LRO is dropped on a upper device (by the new
> code added in this patch), all lower devices will need to drop it too?
>
> If that's what you are saying, it's already taken care of. There is
> netdev_sync_upper_features() and netdev_sync_lower_features() that
> will automatically do that as part of __netdev_update_features().
>
>>
>>> LRO and GRO_HW are different. We may never agree on this but they are
>>> different. If a bond needs to disable LRO, it will be propagated to
>>> all slaves. But each slave can have GRO enabled. If GRO is enabled,
>>> GRO_HW, being a subset of GRO, can be enabled.
>>
>> I get that they are very different. At a driver level it makes sense
>> to say you get one or the other at a physical driver level. The point
>> I was trying to make is that the bond is only able to set one or the
>> other when you might have a mix of devices. On the bonding device you
>> should be able to have both LRO and GRO_HW enabled.
>
> On the bond, you can have LRO enabled and it is propagated to lower
> devices so that lower devices will enable LRO if it is supported. If
> LRO is disabled on the bond (e.g. due to bridging), It will be
> propagated so all lower devices will disable LRO if it is enabled.
>
> GRO/GRO_HW is different and it is not propagated from upper devices to
> lower devices like LRO. Lower devices can have GRO/GRO_HW
> enabled/disabled regardless of upper device. This is no different
> from say RXCSUM. Lower devices can have RXCSUM on/off regardless.
So on the bond device you should be able to have LRO, GRO, and GRO_HW
enabled all at the same time and that means devices below it can have
any combination of those enabled. If I recall enabling it on the lower
device shouldn't be allowed if an upper device has it disabled. If it
is enabled on the upper device it can be either enabled or disabled on
the lower device depending on the state the device prefers.
The GRO and GRO_HW should be propagated just like RXCSUM and
everything else. Basically if I turn it off on the bond all of the
lower devices should have it disabled. Only if it is enabled should
lower devices be allowed to have it either enabled or disabled. The
easiest way to think of it is on the bond the features are like a mask
of what can be enabled/disabled for the lower devices. If a feature is
not present in the bond it should not be present on any of the devices
below it. That is why I am saying you cannot say LRO and GRO_HW are
mutually exclusive for all devices. For physical devices I would say
yes it can be mutually exclusive, but for things like bond it cannot
be since you can have one device doing LRO and one device doing GRO_HW
getting added to a bond and both features should be advertised there.
My concern is if I have a bond with both GRO_HW and LRO enabled on
lower devices, and then disable something like TSO we are going to see
LRO disabled on the bond and propagated to all the lower devices. That
is a bad behavior and shouldn't happen. In addition I would want to be
able to disable GRO_HW from the bond should I encounter a buggy
implementation of the GRO hardware offload at some point in the
future. I don't like it being tied so closely with GRO since all it
takes is one hardware failure and then we are dealing with people
disabling GRO due to reports of it being buggy instead of it being
tied specifically to GRO_HW.
- Alex
^ permalink raw reply
* [PATCH net-next] net: stmmac: fix broken dma_interrupt handling for multi-queues
From: Niklas Cassel @ 2017-12-07 22:56 UTC (permalink / raw)
To: Joao.Pinto, Giuseppe Cavallaro, Alexandre Torgue
Cc: Niklas Cassel, netdev, linux-kernel
There is nothing that says that number of TX queues == number of RX
queues. E.g. the ARTPEC-6 SoC has 2 TX queues and 1 RX queue.
This code is obviously wrong:
for (chan = 0; chan < tx_channel_count; chan++) {
struct stmmac_rx_queue *rx_q = &priv->rx_queue[chan];
priv->rx_queue has size MTL_MAX_RX_QUEUES, so this will send an
uninitialized napi_struct to __napi_schedule(), causing us to
crash in net_rx_action(), because napi_struct->poll is zero.
[12846.759880] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[12846.768014] pgd = (ptrval)
[12846.770742] [00000000] *pgd=39ec7831, *pte=00000000, *ppte=00000000
[12846.777023] Internal error: Oops: 80000007 [#1] PREEMPT SMP ARM
[12846.782942] Modules linked in:
[12846.785998] CPU: 0 PID: 161 Comm: dropbear Not tainted 4.15.0-rc2-00285-gf5fb5f2f39a7 #36
[12846.794177] Hardware name: Axis ARTPEC-6 Platform
[12846.798879] task: (ptrval) task.stack: (ptrval)
[12846.803407] PC is at 0x0
[12846.805942] LR is at net_rx_action+0x274/0x43c
[12846.810383] pc : [<00000000>] lr : [<80bff064>] psr: 200e0113
[12846.816648] sp : b90d9ae8 ip : b90d9ae8 fp : b90d9b44
[12846.821871] r10: 00000008 r9 : 0013250e r8 : 00000100
[12846.827094] r7 : 0000012c r6 : 00000000 r5 : 00000001 r4 : bac84900
[12846.833619] r3 : 00000000 r2 : b90d9b08 r1 : 00000000 r0 : bac84900
Since each DMA channel can be used for rx and tx simultaneously,
the current code should probably be rewritten so that napi_struct is
embedded in a new struct stmmac_channel.
That way, stmmac_poll() can call stmmac_tx_clean() on just the tx queue
where we got the IRQ, instead of looping through all tx queues.
This is also how the xgbe driver does it (another driver for this IP).
Fixes: c22a3f48ef99 ("net: stmmac: adding multiple napi mechanism")
Signed-off-by: Niklas Cassel <niklas.cassel@axis.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 54 +++++++++++++++++++----
1 file changed, 46 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index d7250539d0bd..c52a9963c19d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1997,22 +1997,60 @@ static void stmmac_set_dma_operation_mode(struct stmmac_priv *priv, u32 txmode,
static void stmmac_dma_interrupt(struct stmmac_priv *priv)
{
u32 tx_channel_count = priv->plat->tx_queues_to_use;
- int status;
+ u32 rx_channel_count = priv->plat->rx_queues_to_use;
+ u32 channels_to_check = tx_channel_count > rx_channel_count ?
+ tx_channel_count : rx_channel_count;
u32 chan;
+ bool poll_scheduled = false;
+ int status[channels_to_check];
+
+ /* Each DMA channel can be used for rx and tx simultaneously, yet
+ * napi_struct is embedded in struct stmmac_rx_queue rather than in a
+ * stmmac_channel struct.
+ * Because of this, stmmac_poll currently checks (and possibly wakes)
+ * all tx queues rather than just a single tx queue.
+ */
+ for (chan = 0; chan < channels_to_check; chan++)
+ status[chan] = priv->hw->dma->dma_interrupt(priv->ioaddr,
+ &priv->xstats,
+ chan);
- for (chan = 0; chan < tx_channel_count; chan++) {
- struct stmmac_rx_queue *rx_q = &priv->rx_queue[chan];
+ for (chan = 0; chan < rx_channel_count; chan++) {
+ if (likely(status[chan] & handle_rx)) {
+ struct stmmac_rx_queue *rx_q = &priv->rx_queue[chan];
- status = priv->hw->dma->dma_interrupt(priv->ioaddr,
- &priv->xstats, chan);
- if (likely((status & handle_rx)) || (status & handle_tx)) {
if (likely(napi_schedule_prep(&rx_q->napi))) {
stmmac_disable_dma_irq(priv, chan);
__napi_schedule(&rx_q->napi);
+ poll_scheduled = true;
+ }
+ }
+ }
+
+ /* If we scheduled poll, we already know that tx queues will be checked.
+ * If we didn't schedule poll, see if any DMA channel (used by tx) has a
+ * completed transmission, if so, call stmmac_poll (once).
+ */
+ if (!poll_scheduled) {
+ for (chan = 0; chan < tx_channel_count; chan++) {
+ if (status[chan] & handle_tx) {
+ /* It doesn't matter what rx queue we choose
+ * here. We use 0 since it always exists.
+ */
+ struct stmmac_rx_queue *rx_q =
+ &priv->rx_queue[0];
+
+ if (likely(napi_schedule_prep(&rx_q->napi))) {
+ stmmac_disable_dma_irq(priv, chan);
+ __napi_schedule(&rx_q->napi);
+ }
+ break;
}
}
+ }
- if (unlikely(status & tx_hard_error_bump_tc)) {
+ for (chan = 0; chan < tx_channel_count; chan++) {
+ if (unlikely(status[chan] & tx_hard_error_bump_tc)) {
/* Try to bump up the dma threshold on this failure */
if (unlikely(priv->xstats.threshold != SF_DMA_MODE) &&
(tc <= 256)) {
@@ -2029,7 +2067,7 @@ static void stmmac_dma_interrupt(struct stmmac_priv *priv)
chan);
priv->xstats.threshold = tc;
}
- } else if (unlikely(status == tx_hard_error)) {
+ } else if (unlikely(status[chan] == tx_hard_error)) {
stmmac_tx_err(priv, chan);
}
}
--
2.14.2
^ permalink raw reply related
* Re: [PATCH v2 net-next 4/4] bpftool: implement cgroup bpf operations
From: Philippe Ombredanne @ 2017-12-07 23:00 UTC (permalink / raw)
To: Roman Gushchin
Cc: Jakub Kicinski, netdev, LKML, kernel-team, ast, daniel, kafai,
Quentin Monnet, David Ahern
In-Reply-To: <20171207142306.285be14c@cakuba.netronome.com>
Roman,
On Thu, Dec 7, 2017 at 11:23 PM, Jakub Kicinski
<jakub.kicinski@netronome.com> wrote:
> On Thu, 7 Dec 2017 18:39:09 +0000, Roman Gushchin wrote:
>> This patch adds basic cgroup bpf operations to bpftool:
>> cgroup list, attach and detach commands.
>>
>> Usage is described in the corresponding man pages,
>> and examples are provided.
>>
>> Syntax:
>> $ bpftool cgroup list CGROUP
>> $ bpftool cgroup attach CGROUP ATTACH_TYPE PROG [ATTACH_FLAGS]
>> $ bpftool cgroup detach CGROUP ATTACH_TYPE PROG
>>
>> Signed-off-by: Roman Gushchin <guro@fb.com>
>
> Looks good, a few very minor nits/questions below.
>
>> diff --git a/tools/bpf/bpftool/cgroup.c b/tools/bpf/bpftool/cgroup.c
>> new file mode 100644
>> index 000000000000..88d67f74313f
>> --- /dev/null
>> +++ b/tools/bpf/bpftool/cgroup.c
>> @@ -0,0 +1,305 @@
>> +/*
>> + * Copyright (C) 2017 Facebook
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License
>> + * as published by the Free Software Foundation; either version
>> + * 2 of the License, or (at your option) any later version.
>> + *
>> + * Author: Roman Gushchin <guro@fb.com>
>> + */
Have you considered using the new SPDX ids instead?
e.g. may be something like:
// SPDX-License-Identifier: GPL-2.0+
// Copyright (C) 2017 Facebook
// Author: Roman Gushchin <guro@fb.com>
Don't you love it with less boilerplate and a better code/comments ratio?
BTW the comment style may surprise you here: this is a suggestion, but
not just. Check the posts from Linus on this topic and Thomas's doc
patches for the rationale.
Thank you for your kind consideration!
--
Cordially
Philippe Ombredanne
^ permalink raw reply
* [PATCH net-next 0/2] tools: bpftool: clean up and extend Makefiles
From: Jakub Kicinski @ 2017-12-07 23:00 UTC (permalink / raw)
To: netdev; +Cc: oss-drivers, daniel, alexei.starovoitov, Jakub Kicinski
Hi!
This is a follow up to a series of Makefile fixes for bpftool from
two weeks ago. I think there will have to be a merge back of net-next
into bpf-next (or rebase), AFAICT the previous series arrived in
net-next already, but not in bpf-next. I hope that makes sense.
FWIW this should not conflict with Roman's cgroup work.
Quentin says:
First patch of this series cleans up the two Makefiles (Makefile and
Documentation/Makefile) and make their contents more consistent.
The second one add "uninstall" and "doc-uninstall" targets, to remove files
previously installed on the system with "install" and "doc-install"
targets.
Quentin Monnet (2):
tools: bpftool: harmonise Makefile and Documentation/Makefile
tools: bpftool: create "uninstall", "doc-uninstall" make targets
tools/bpf/bpftool/Documentation/Makefile | 30 ++++++++++------
tools/bpf/bpftool/Makefile | 61 ++++++++++++++++----------------
tools/scripts/Makefile.include | 1 +
3 files changed, 52 insertions(+), 40 deletions(-)
--
2.15.1
^ permalink raw reply
* [PATCH net-next 1/2] tools: bpftool: harmonise Makefile and Documentation/Makefile
From: Jakub Kicinski @ 2017-12-07 23:00 UTC (permalink / raw)
To: netdev; +Cc: oss-drivers, daniel, alexei.starovoitov, Quentin Monnet
In-Reply-To: <20171207230018.7510-1-jakub.kicinski@netronome.com>
From: Quentin Monnet <quentin.monnet@netronome.com>
Several minor fixes and harmonisation items for Makefiles:
* Use the same mechanism for verbose/non-verbose output in two files
("$(Q)"), for all commands.
* Use calls to "QUIET_INSTALL" and equivalent in Makefile. In
particular, use "call(descend,…)" instead of "make -C" to run
documentation targets.
* Add a "doc-clean" target, aligned on "doc" and "doc-install".
* Make "install" target in Makefile depend on "bpftool".
* Remove condition on DESTDIR to initialise prefix in doc Makefile.
* Remove modification of VPATH based on OUTPUT, it is unused.
* Formatting: harmonise spaces around equal signs.
* Make install path for man pages /usr/local/man instead of
/usr/local/share/man (respects the Makefile conventions, and the
latter is usually a symbolic link to the former anyway).
* Do not erase prefix if set by user in bpftool Makefile.
* Fix install target for bpftool: append DESTDIR to install path.
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
---
tools/bpf/bpftool/Documentation/Makefile | 22 +++++++------
tools/bpf/bpftool/Makefile | 53 ++++++++++++++------------------
2 files changed, 36 insertions(+), 39 deletions(-)
diff --git a/tools/bpf/bpftool/Documentation/Makefile b/tools/bpf/bpftool/Documentation/Makefile
index 37292bb5ce60..71c17fab4f2f 100644
--- a/tools/bpf/bpftool/Documentation/Makefile
+++ b/tools/bpf/bpftool/Documentation/Makefile
@@ -4,11 +4,14 @@ include ../../../scripts/utilities.mak
INSTALL ?= install
RM ?= rm -f
-# Make the path relative to DESTDIR, not prefix
-ifndef DESTDIR
-prefix ?= /usr/local
+ifeq ($(V),1)
+ Q =
+else
+ Q = @
endif
-mandir ?= $(prefix)/share/man
+
+prefix ?= /usr/local
+mandir ?= $(prefix)/man
man8dir = $(mandir)/man8
MAN8_RST = $(wildcard *.rst)
@@ -20,15 +23,16 @@ man: man8
man8: $(DOC_MAN8)
$(OUTPUT)%.8: %.rst
- rst2man $< > $@
+ $(QUIET_GEN)rst2man $< > $@
clean:
- $(call QUIET_CLEAN, Documentation) $(RM) $(DOC_MAN8)
+ $(call QUIET_CLEAN, Documentation)
+ $(Q)$(RM) $(DOC_MAN8)
install: man
- $(call QUIET_INSTALL, Documentation-man) \
- $(INSTALL) -d -m 755 $(DESTDIR)$(man8dir); \
- $(INSTALL) -m 644 $(DOC_MAN8) $(DESTDIR)$(man8dir);
+ $(call QUIET_INSTALL, Documentation-man)
+ $(Q)$(INSTALL) -d -m 755 $(DESTDIR)$(man8dir)
+ $(Q)$(INSTALL) -m 644 $(DOC_MAN8) $(DESTDIR)$(man8dir)
.PHONY: man man8 clean install
.DEFAULT_GOAL := man
diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile
index ec3052c0b004..203ae2e14fbc 100644
--- a/tools/bpf/bpftool/Makefile
+++ b/tools/bpf/bpftool/Makefile
@@ -1,25 +1,10 @@
include ../../scripts/Makefile.include
-
include ../../scripts/utilities.mak
ifeq ($(srctree),)
srctree := $(patsubst %/,%,$(dir $(CURDIR)))
srctree := $(patsubst %/,%,$(dir $(srctree)))
srctree := $(patsubst %/,%,$(dir $(srctree)))
-#$(info Determined 'srctree' to be $(srctree))
-endif
-
-ifneq ($(objtree),)
-#$(info Determined 'objtree' to be $(objtree))
-endif
-
-ifneq ($(OUTPUT),)
-#$(info Determined 'OUTPUT' to be $(OUTPUT))
-# Adding $(OUTPUT) as a directory to look for source files,
-# because use generated output files as sources dependency
-# for flex/bison parsers.
-VPATH += $(OUTPUT)
-export VPATH
endif
ifeq ($(V),1)
@@ -28,12 +13,12 @@ else
Q = @
endif
-BPF_DIR = $(srctree)/tools/lib/bpf/
+BPF_DIR = $(srctree)/tools/lib/bpf/
ifneq ($(OUTPUT),)
- BPF_PATH=$(OUTPUT)
+ BPF_PATH = $(OUTPUT)
else
- BPF_PATH=$(BPF_DIR)
+ BPF_PATH = $(BPF_DIR)
endif
LIBBPF = $(BPF_PATH)libbpf.a
@@ -45,7 +30,7 @@ $(LIBBPF): FORCE
$(call QUIET_CLEAN, libbpf)
$(Q)$(MAKE) -C $(BPF_DIR) OUTPUT=$(OUTPUT) clean >/dev/null
-prefix = /usr/local
+prefix ?= /usr/local
bash_compdir ?= /usr/share/bash-completion/completions
CC = gcc
@@ -55,12 +40,15 @@ CFLAGS += -W -Wall -Wextra -Wno-unused-parameter -Wshadow
CFLAGS += -D__EXPORTED_HEADERS__ -I$(srctree)/tools/include/uapi -I$(srctree)/tools/include -I$(srctree)/tools/lib/bpf -I$(srctree)/kernel/bpf/
LIBS = -lelf -lbfd -lopcodes $(LIBBPF)
+INSTALL ?= install
+RM ?= rm -f
+
include $(wildcard *.d)
all: $(OUTPUT)bpftool
-SRCS=$(wildcard *.c)
-OBJS=$(patsubst %.c,$(OUTPUT)%.o,$(SRCS)) $(OUTPUT)disasm.o
+SRCS = $(wildcard *.c)
+OBJS = $(patsubst %.c,$(OUTPUT)%.o,$(SRCS)) $(OUTPUT)disasm.o
$(OUTPUT)disasm.o: $(srctree)/kernel/bpf/disasm.c
$(QUIET_CC)$(COMPILE.c) -MMD -o $@ $<
@@ -73,21 +61,26 @@ $(OUTPUT)%.o: %.c
clean: $(LIBBPF)-clean
$(call QUIET_CLEAN, bpftool)
- $(Q)rm -rf $(OUTPUT)bpftool $(OUTPUT)*.o $(OUTPUT)*.d
+ $(Q)$(RM) $(OUTPUT)bpftool $(OUTPUT)*.o $(OUTPUT)*.d
-install:
- install -m 0755 -d $(prefix)/sbin
- install $(OUTPUT)bpftool $(prefix)/sbin/bpftool
- install -m 0755 -d $(bash_compdir)
- install -m 0644 bash-completion/bpftool $(bash_compdir)
+install: $(OUTPUT)bpftool
+ $(call QUIET_INSTALL, bpftool)
+ $(Q)$(INSTALL) -m 0755 -d $(DESTDIR)$(prefix)/sbin
+ $(Q)$(INSTALL) $(OUTPUT)bpftool $(DESTDIR)$(prefix)/sbin/bpftool
+ $(Q)$(INSTALL) -m 0755 -d $(DESTDIR)$(bash_compdir)
+ $(Q)$(INSTALL) -m 0644 bash-completion/bpftool $(DESTDIR)$(bash_compdir)
doc:
- $(Q)$(MAKE) -C Documentation/
+ $(call descend,Documentation)
+
+doc-clean:
+ $(call descend,Documentation,clean)
doc-install:
- $(Q)$(MAKE) -C Documentation/ install
+ $(call descend,Documentation,install)
FORCE:
-.PHONY: all clean FORCE install doc doc-install
+.PHONY: all FORCE clean install
+.PHONY: doc doc-clean doc-install
.DEFAULT_GOAL := all
--
2.15.1
^ permalink raw reply related
* [PATCH net-next 2/2] tools: bpftool: create "uninstall", "doc-uninstall" make targets
From: Jakub Kicinski @ 2017-12-07 23:00 UTC (permalink / raw)
To: netdev
Cc: oss-drivers, daniel, alexei.starovoitov, Quentin Monnet,
Arnaldo Carvalho de Melo, Masahiro Yamada
In-Reply-To: <20171207230018.7510-1-jakub.kicinski@netronome.com>
From: Quentin Monnet <quentin.monnet@netronome.com>
Create two targets to remove executable and documentation that would
have been previously installed with `make install` and `make
doc-install`.
Also create a "QUIET_UNINST" helper in tools/scripts/Makefile.include.
Do not attempt to remove directories /usr/local/sbin and
/usr/share/bash-completions/completions, even if they are empty, as
those specific directories probably already existed on the system before
we installed the program, and we do not wish to break other makefiles
that might assume their existence. Do remvoe /usr/local/share/man/man8
if empty however, as this directory does not seem to exist by default.
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
---
For addition to tools/scripts/Makefile.include:
CC: Arnaldo Carvalho de Melo <acme@redhat.com>
CC: Masahiro Yamada <yamada.masahiro@socionext.com>
tools/bpf/bpftool/Documentation/Makefile | 8 +++++++-
tools/bpf/bpftool/Makefile | 12 ++++++++++--
tools/scripts/Makefile.include | 1 +
3 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/tools/bpf/bpftool/Documentation/Makefile b/tools/bpf/bpftool/Documentation/Makefile
index 71c17fab4f2f..c462a928e03d 100644
--- a/tools/bpf/bpftool/Documentation/Makefile
+++ b/tools/bpf/bpftool/Documentation/Makefile
@@ -3,6 +3,7 @@ include ../../../scripts/utilities.mak
INSTALL ?= install
RM ?= rm -f
+RMDIR ?= rmdir --ignore-fail-on-non-empty
ifeq ($(V),1)
Q =
@@ -34,5 +35,10 @@ install: man
$(Q)$(INSTALL) -d -m 755 $(DESTDIR)$(man8dir)
$(Q)$(INSTALL) -m 644 $(DOC_MAN8) $(DESTDIR)$(man8dir)
-.PHONY: man man8 clean install
+uninstall:
+ $(call QUIET_UNINST, Documentation-man)
+ $(Q)$(RM) $(addprefix $(DESTDIR)$(man8dir)/,$(_DOC_MAN8))
+ $(Q)$(RMDIR) $(DESTDIR)$(man8dir)
+
+.PHONY: man man8 clean install uninstall
.DEFAULT_GOAL := man
diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile
index 203ae2e14fbc..3f17ad317512 100644
--- a/tools/bpf/bpftool/Makefile
+++ b/tools/bpf/bpftool/Makefile
@@ -70,6 +70,11 @@ install: $(OUTPUT)bpftool
$(Q)$(INSTALL) -m 0755 -d $(DESTDIR)$(bash_compdir)
$(Q)$(INSTALL) -m 0644 bash-completion/bpftool $(DESTDIR)$(bash_compdir)
+uninstall:
+ $(call QUIET_UNINST, bpftool)
+ $(Q)$(RM) $(DESTDIR)$(prefix)/sbin/bpftool
+ $(Q)$(RM) $(DESTDIR)$(bash_compdir)/bpftool
+
doc:
$(call descend,Documentation)
@@ -79,8 +84,11 @@ install: $(OUTPUT)bpftool
doc-install:
$(call descend,Documentation,install)
+doc-uninstall:
+ $(call descend,Documentation,uninstall)
+
FORCE:
-.PHONY: all FORCE clean install
-.PHONY: doc doc-clean doc-install
+.PHONY: all FORCE clean install uninstall
+.PHONY: doc doc-clean doc-install doc-uninstall
.DEFAULT_GOAL := all
diff --git a/tools/scripts/Makefile.include b/tools/scripts/Makefile.include
index 3fab179b1aba..fcb3ed0be5f8 100644
--- a/tools/scripts/Makefile.include
+++ b/tools/scripts/Makefile.include
@@ -99,5 +99,6 @@ ifneq ($(silent),1)
QUIET_CLEAN = @printf ' CLEAN %s\n' $1;
QUIET_INSTALL = @printf ' INSTALL %s\n' $1;
+ QUIET_UNINST = @printf ' UNINST %s\n' $1;
endif
endif
--
2.15.1
^ permalink raw reply related
* [PATCH next] ipvlan: add L2 check for packets arriving via virtual devices
From: Mahesh Bandewar @ 2017-12-07 23:15 UTC (permalink / raw)
To: David Miller, Netdev
Cc: Eric Dumazet, Mahesh Bandewar, Amit Sikka, Mahesh Bandewar
From: Mahesh Bandewar <maheshb@google.com>
Packets that don't have dest mac as the mac of the master device should
not be entertained by the IPvlan rx-handler. This is mostly true as the
packet path mostly takes care of that, except when the master device is
a virtual device. As demonstrated in the following case -
ip netns add ns1
ip link add ve1 type veth peer name ve2
ip link add link ve2 name iv1 type ipvlan mode l2
ip link set dev iv1 netns ns1
ip link set ve1 up
ip link set ve2 up
ip -n ns1 link set iv1 up
ip addr add 192.168.10.1/24 dev ve1
ip -n ns1 addr 192.168.10.2/24 dev iv1
ping -c2 192.168.10.2
<Works!>
ip neigh show dev ve1
ip neigh show 192.168.10.2 lladdr <random> dev ve1
ping -c2 192.168.10.2
<Still works! Wrong!!>
This patch adds that missing check in the IPvlan rx-handler.
Reported-by: Amit Sikka <amit.sikka@ericsson.com>
Signed-off-by: Mahesh Bandewar <maheshb@google.com>
---
drivers/net/ipvlan/ipvlan_core.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ipvlan/ipvlan_core.c b/drivers/net/ipvlan/ipvlan_core.c
index 9774c96ac7bb..0bc7f721b717 100644
--- a/drivers/net/ipvlan/ipvlan_core.c
+++ b/drivers/net/ipvlan/ipvlan_core.c
@@ -322,6 +322,10 @@ static int ipvlan_rcv_frame(struct ipvl_addr *addr, struct sk_buff **pskb,
if (dev_forward_skb(ipvlan->dev, skb) == NET_RX_SUCCESS)
success = true;
} else {
+ if (!ether_addr_equal_64bits(eth_hdr(skb)->h_dest,
+ ipvlan->phy_dev->dev_addr))
+ skb->pkt_type = PACKET_OTHERHOST;
+
ret = RX_HANDLER_ANOTHER;
success = true;
}
--
2.15.1.424.g9478a66081-goog
^ permalink raw reply related
* Re: [PATCH net-next v2 1/5] net: Introduce NETIF_F_GRO_HW.
From: Michael Chan @ 2017-12-07 23:17 UTC (permalink / raw)
To: Alexander Duyck
Cc: David Miller, Netdev, Andrew Gospodarek, Ariel Elior,
everest-linux-l2
In-Reply-To: <CAKgT0UdCRhiMHx4MS1zWQhBgMOYd0+9Go_a8753WW=-2c58L2Q@mail.gmail.com>
On Thu, Dec 7, 2017 at 2:43 PM, Alexander Duyck
<alexander.duyck@gmail.com> wrote:
> On Thu, Dec 7, 2017 at 2:08 PM, Michael Chan <michael.chan@broadcom.com> wrote:
>> On the bond, you can have LRO enabled and it is propagated to lower
>> devices so that lower devices will enable LRO if it is supported. If
>> LRO is disabled on the bond (e.g. due to bridging), It will be
>> propagated so all lower devices will disable LRO if it is enabled.
>>
>> GRO/GRO_HW is different and it is not propagated from upper devices to
>> lower devices like LRO. Lower devices can have GRO/GRO_HW
>> enabled/disabled regardless of upper device. This is no different
>> from say RXCSUM. Lower devices can have RXCSUM on/off regardless.
>
> So on the bond device you should be able to have LRO, GRO, and GRO_HW
> enabled all at the same time and that means devices below it can have
> any combination of those enabled. If I recall enabling it on the lower
> device shouldn't be allowed if an upper device has it disabled. If it
> is enabled on the upper device it can be either enabled or disabled on
> the lower device depending on the state the device prefers.
Only LRO behaves the way you describe. I believe LRO is treated like
this differently because bridging or routing needs to be able to
disable it completely.
GRO is not like that. RXCSUM is not like that.
>
> The GRO and GRO_HW should be propagated just like RXCSUM and
> everything else. Basically if I turn it off on the bond all of the
> lower devices should have it disabled. Only if it is enabled should
> lower devices be allowed to have it either enabled or disabled. The
> easiest way to think of it is on the bond the features are like a mask
> of what can be enabled/disabled for the lower devices. If a feature is
> not present in the bond it should not be present on any of the devices
> below it. That is why I am saying you cannot say LRO and GRO_HW are
> mutually exclusive for all devices. For physical devices I would say
> yes it can be mutually exclusive, but for things like bond it cannot
> be since you can have one device doing LRO and one device doing GRO_HW
> getting added to a bond and both features should be advertised there.
I think you keep thinking that whatever we do with LRO, we must do the
same thing with GRO_HW.
But that's not true. GRO/GRO_HW don't have to be disabled when
bridging/routing are enabled. That's why upper devices don't have to
treat GRO/GRO_HW like LRO. It can be treated just like RXCSUM which
is don't care.
>
> My concern is if I have a bond with both GRO_HW and LRO enabled on
> lower devices, and then disable something like TSO we are going to see
> LRO disabled on the bond and propagated to all the lower devices.
I don't get this. I don't see how TSO is related.
> That
> is a bad behavior and shouldn't happen. In addition I would want to be
> able to disable GRO_HW from the bond should I encounter a buggy
> implementation of the GRO hardware offload at some point in the
> future. I don't like it being tied so closely with GRO since all it
> takes is one hardware failure and then we are dealing with people
> disabling GRO due to reports of it being buggy instead of it being
> tied specifically to GRO_HW.
>
Today, GRO, RXCSUM, NTUPLE, etc on a bond do not get propagated. You
can propose and make them propagate if you want.
So GRO_HW just naturally follows GRO since it is a true subset of it.
^ permalink raw reply
* Re: [PATCH net-next v2 1/5] net: Introduce NETIF_F_GRO_HW.
From: Alexander Duyck @ 2017-12-07 23:35 UTC (permalink / raw)
To: Michael Chan
Cc: David Miller, Netdev, Andrew Gospodarek, Ariel Elior,
everest-linux-l2
In-Reply-To: <CACKFLik5dEaVsbgybPk0dKSVN8j+w6BLVT_thRzxsXkQMmeuKA@mail.gmail.com>
On Thu, Dec 7, 2017 at 3:17 PM, Michael Chan <michael.chan@broadcom.com> wrote:
> On Thu, Dec 7, 2017 at 2:43 PM, Alexander Duyck
> <alexander.duyck@gmail.com> wrote:
>> On Thu, Dec 7, 2017 at 2:08 PM, Michael Chan <michael.chan@broadcom.com> wrote:
>>> On the bond, you can have LRO enabled and it is propagated to lower
>>> devices so that lower devices will enable LRO if it is supported. If
>>> LRO is disabled on the bond (e.g. due to bridging), It will be
>>> propagated so all lower devices will disable LRO if it is enabled.
>>>
>>> GRO/GRO_HW is different and it is not propagated from upper devices to
>>> lower devices like LRO. Lower devices can have GRO/GRO_HW
>>> enabled/disabled regardless of upper device. This is no different
>>> from say RXCSUM. Lower devices can have RXCSUM on/off regardless.
>>
>> So on the bond device you should be able to have LRO, GRO, and GRO_HW
>> enabled all at the same time and that means devices below it can have
>> any combination of those enabled. If I recall enabling it on the lower
>> device shouldn't be allowed if an upper device has it disabled. If it
>> is enabled on the upper device it can be either enabled or disabled on
>> the lower device depending on the state the device prefers.
>
> Only LRO behaves the way you describe. I believe LRO is treated like
> this differently because bridging or routing needs to be able to
> disable it completely.
>
> GRO is not like that. RXCSUM is not like that.
I think that what your saying is your patch has exposed a bug. If I
disable GRO or GRO_HW on the upper device I would expect to have it
disabled on all lower devices. If anything it should probably be added
to NETIF_F_UPPER_DISABLES. Otherwise we are going to be breaking
things like XPS which you pointed out earlier.
>> The GRO and GRO_HW should be propagated just like RXCSUM and
>> everything else. Basically if I turn it off on the bond all of the
>> lower devices should have it disabled. Only if it is enabled should
>> lower devices be allowed to have it either enabled or disabled. The
>> easiest way to think of it is on the bond the features are like a mask
>> of what can be enabled/disabled for the lower devices. If a feature is
>> not present in the bond it should not be present on any of the devices
>> below it. That is why I am saying you cannot say LRO and GRO_HW are
>> mutually exclusive for all devices. For physical devices I would say
>> yes it can be mutually exclusive, but for things like bond it cannot
>> be since you can have one device doing LRO and one device doing GRO_HW
>> getting added to a bond and both features should be advertised there.
>
> I think you keep thinking that whatever we do with LRO, we must do the
> same thing with GRO_HW.
>
> But that's not true. GRO/GRO_HW don't have to be disabled when
> bridging/routing are enabled. That's why upper devices don't have to
> treat GRO/GRO_HW like LRO. It can be treated just like RXCSUM which
> is don't care.
>
>>
>> My concern is if I have a bond with both GRO_HW and LRO enabled on
>> lower devices, and then disable something like TSO we are going to see
>> LRO disabled on the bond and propagated to all the lower devices.
>
> I don't get this. I don't see how TSO is related.
It isn't. That is the point. If I change ANY feature it will trigger
fix_features to get called. It will then see we have GRO_HW and LRO
since we have one interface that supports one and one that supports
another. It will trigger this code and cause LRO to be disabled which
then will be propagated down.
>> That
>> is a bad behavior and shouldn't happen. In addition I would want to be
>> able to disable GRO_HW from the bond should I encounter a buggy
>> implementation of the GRO hardware offload at some point in the
>> future. I don't like it being tied so closely with GRO since all it
>> takes is one hardware failure and then we are dealing with people
>> disabling GRO due to reports of it being buggy instead of it being
>> tied specifically to GRO_HW.
>>
>
> Today, GRO, RXCSUM, NTUPLE, etc on a bond do not get propagated. You
> can propose and make them propagate if you want.
Or you can fix your patches so you take it into account now instead of
putting things in a broken state and asking others to fix it.
> So GRO_HW just naturally follows GRO since it is a true subset of it.
Right, and I am saying you have exposed a bug. If I don't want GRO on
the bond it should be propagated down. It doesn't make sense to allow
lower devices to assemble frames when the bond doesn't want them and
GSO won't kick in before it gets to the bond.
^ permalink raw reply
* Re: [PATCH V2] selinux: Add SCTP support
From: Paul Moore @ 2017-12-07 23:37 UTC (permalink / raw)
To: Richard Haines
Cc: selinux, netdev, linux-sctp, linux-security-module, Vlad Yasevich,
nhorman, Stephen Smalley, Eric Paris, marcelo.leitner
In-Reply-To: <20171206101736.3217-1-richard_c_haines@btinternet.com>
On Wed, Dec 6, 2017 at 5:17 AM, Richard Haines
<richard_c_haines@btinternet.com> wrote:
> The SELinux SCTP implementation is explained in:
> Documentation/security/SELinux-sctp.rst
>
> Signed-off-by: Richard Haines <richard_c_haines@btinternet.com>
> ---
> V2 Changes
> Remove lock from selinux_sctp_assoc_request()
> Fix selinux_sctp_sk_clone() kbuild test robot catch [1]
>
> [1] https://marc.info/?l=selinux&m=151198281817779&w=2
>
> Documentation/security/SELinux-sctp.rst | 104 ++++++++++++
> security/selinux/hooks.c | 270 +++++++++++++++++++++++++++++---
> security/selinux/include/classmap.h | 2 +-
> security/selinux/include/netlabel.h | 20 ++-
> security/selinux/include/objsec.h | 4 +
> security/selinux/netlabel.c | 144 +++++++++++++++--
> 6 files changed, 512 insertions(+), 32 deletions(-)
> create mode 100644 Documentation/security/SELinux-sctp.rst
I just went through these patches again, and I think they look pretty
good. There is one small cosmetic nit (see below), but that should be
a quick fix.
As Dave already said, let's give the SCTP folks some time to look
things over before I merge anything. If we haven't heard anything by
next week, I'll ping Vlad to see if I can get him to take a look.
> +/**
> + * selinux_netlbl_socket_connect - Label a client-side socket on connect
> + * @sk: the socket to label
> + * @addr: the destination address
> + *
> + * Description:
> + * Attempt to label a connected socket with NetLabel using the given address.
> + * Returns zero values on success, negative values on failure.
> + *
> + */
> +int selinux_netlbl_socket_connect(struct sock *sk, struct sockaddr *addr)
> +{
> + int rc;
> + struct sk_security_struct *sksec = sk->sk_security;
> +
> + if (sksec->nlbl_state != NLBL_REQSKB &&
> + sksec->nlbl_state != NLBL_CONNLABELED)
> + return 0;
> +
> + lock_sock(sk);
> + rc = selinux_netlbl_socket_connect_helper(sk, addr);
> release_sock(sk);
> +
> + return rc;
> +}
> +
> +/**
> + * selinux_netlbl_sctp_socket_connect - Label an SCTP client-side socket on a
> + * connect
> + * @sk: the socket to label
> + * @addr: the destination address
> + *
> + * Description:
> + * Attempt to label a connected socket with NetLabel using the given address
> + * when called by the SCTP protocol layer. The situations handled are:
> + * sctp_connectx(3), sctp_sendmsg(3), sendmsg(2), whenever a new IP address
> + * is added or when a new primary address is selected. Note that an SCTP
> + * connect(2) call happens before the SCTP protocol layer and is handled via
> + * selinux_netlbl_socket_connect()
> + * Returns zero values on success, negative values on failure.
> + *
> + */
> +int selinux_netlbl_sctp_socket_connect(struct sock *sk, struct sockaddr *addr)
> +{
> + int rc;
> + struct sk_security_struct *sksec = sk->sk_security;
> +
> + if (sksec->nlbl_state != NLBL_REQSKB &&
> + sksec->nlbl_state != NLBL_CONNLABELED)
> + return 0;
> +
> + rc = selinux_netlbl_socket_connect_helper(sk, addr);
> +
> return rc;
> }
My apologies, I should have noticed this sooner ... If the only
difference between selinux_netlbl_socket_connect() and
selinux_netlbl_sctp_socket_connect() is that the SCTP variant takes a
lock, why not simply rename selinux_netlbl_sctp_socket_connect() to
selinux_netlbl_socket_connect_locked()? There is nothing really SCTP
specific here, aside from the comment header, which should already be
covered elsewhere.
[NOTE TO MYSELF: pick shorter function names next time, oof.]
--
paul moore
www.paul-moore.com
^ permalink raw reply
* [PATCH net-next v3 0/2] veth and GSO maximums
From: Stephen Hemminger @ 2017-12-07 23:40 UTC (permalink / raw)
To: davem; +Cc: netdev, Stephen Hemminger
This is the more general way to solving the issue of GSO limits
not being set correctly for containers on Azure. If a GSO packet
is sent to host that exceeds the limit (reported by NDIS), then
the host is forced to do segmentation in software which has noticeable
performance impact.
The core rtnetlink infrastructure already has the messages and
infrastructure to allow changing gso limits. With an updated iproute2
the following already works:
# ip li set dev dummy0 gso_max_size 30000
These patches are about making it easier with veth.
Stephen Hemminger (2):
rtnetlink: allow GSO maximums to be set on device creation
veth: set peer GSO values
drivers/net/veth.c | 3 +++
net/core/rtnetlink.c | 34 ++++++++++++++++++++++++++++++++++
2 files changed, 37 insertions(+)
--
2.11.0
^ permalink raw reply
* [PATCH net-next 1/2] rtnetlink: allow GSO maximums to be set on device creation
From: Stephen Hemminger @ 2017-12-07 23:40 UTC (permalink / raw)
To: davem; +Cc: netdev, Stephen Hemminger, Stephen Hemminger
In-Reply-To: <20171207234020.18783-1-sthemmin@microsoft.com>
From: Stephen Hemminger <stephen@networkplumber.org>
Netlink device already allows changing GSO sizes with
ip set command. The part that is missing is allowing overriding
GSO settings on device creation.
Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
allow set gso on create
---
net/core/rtnetlink.c | 34 ++++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index a4faefd65006..412ebf0b09c6 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -1637,6 +1637,8 @@ static const struct nla_policy ifla_policy[IFLA_MAX+1] = {
[IFLA_PROMISCUITY] = { .type = NLA_U32 },
[IFLA_NUM_TX_QUEUES] = { .type = NLA_U32 },
[IFLA_NUM_RX_QUEUES] = { .type = NLA_U32 },
+ [IFLA_GSO_MAX_SEGS] = { .type = NLA_U32 },
+ [IFLA_GSO_MAX_SIZE] = { .type = NLA_U32 },
[IFLA_PHYS_PORT_ID] = { .type = NLA_BINARY, .len = MAX_PHYS_ITEM_ID_LEN },
[IFLA_CARRIER_CHANGES] = { .type = NLA_U32 }, /* ignored */
[IFLA_PHYS_SWITCH_ID] = { .type = NLA_BINARY, .len = MAX_PHYS_ITEM_ID_LEN },
@@ -2287,6 +2289,34 @@ static int do_setlink(const struct sk_buff *skb,
}
}
+ if (tb[IFLA_GSO_MAX_SIZE]) {
+ u32 max_size = nla_get_u32(tb[IFLA_GSO_MAX_SIZE]);
+
+ if (max_size > GSO_MAX_SIZE) {
+ err = -EINVAL;
+ goto errout;
+ }
+
+ if (dev->gso_max_size ^ max_size) {
+ netif_set_gso_max_size(dev, max_size);
+ status |= DO_SETLINK_MODIFIED;
+ }
+ }
+
+ if (tb[IFLA_GSO_MAX_SEGS]) {
+ u32 max_segs = nla_get_u32(tb[IFLA_GSO_MAX_SEGS]);
+
+ if (max_segs > GSO_MAX_SEGS) {
+ err = -EINVAL;
+ goto errout;
+ }
+
+ if (dev->gso_max_segs ^ max_segs) {
+ dev->gso_max_segs = max_segs;
+ status |= DO_SETLINK_MODIFIED;
+ }
+ }
+
if (tb[IFLA_OPERSTATE])
set_operstate(dev, nla_get_u8(tb[IFLA_OPERSTATE]));
@@ -2651,6 +2681,10 @@ struct net_device *rtnl_create_link(struct net *net,
dev->link_mode = nla_get_u8(tb[IFLA_LINKMODE]);
if (tb[IFLA_GROUP])
dev_set_group(dev, nla_get_u32(tb[IFLA_GROUP]));
+ if (tb[IFLA_GSO_MAX_SIZE])
+ netif_set_gso_max_size(dev, nla_get_u32(tb[IFLA_GSO_MAX_SIZE]));
+ if (tb[IFLA_GSO_MAX_SEGS])
+ dev->gso_max_size = nla_get_u32(tb[IFLA_GSO_MAX_SEGS]);
return dev;
}
--
2.11.0
^ permalink raw reply related
* [PATCH net-next 2/2] veth: set peer GSO values
From: Stephen Hemminger @ 2017-12-07 23:40 UTC (permalink / raw)
To: davem; +Cc: netdev, Stephen Hemminger
In-Reply-To: <20171207234020.18783-1-sthemmin@microsoft.com>
When new veth is created, and GSO values have been configured
on one device, clone those values to the peer.
For example:
# ip link add dev vm1 gso_max_size 65530 type veth peer name vm2
This should create vm1 <--> vm2 with both having GSO maximum
size set to 65530.
Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
---
drivers/net/veth.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index f5438d0978ca..a69ad39ee57e 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -410,6 +410,9 @@ static int veth_newlink(struct net *src_net, struct net_device *dev,
if (ifmp && (dev->ifindex != 0))
peer->ifindex = ifmp->ifi_index;
+ peer->gso_max_size = dev->gso_max_size;
+ peer->gso_max_segs = dev->gso_max_segs;
+
err = register_netdevice(peer);
put_net(net);
net = NULL;
--
2.11.0
^ permalink raw reply related
* Re: [PATCH net-next v3 0/2] net: thunderx: add support for PTP clock
From: Jakub Kicinski @ 2017-12-07 23:56 UTC (permalink / raw)
To: Aleksey Makarov
Cc: netdev, linux-arm-kernel, linux-kernel, Goutham, Sunil,
Radoslaw Biernacki, Robert Richter, David Daney, Richard Cochran
In-Reply-To: <20171206133100.26436-1-aleksey.makarov@cavium.com>
On Wed, 6 Dec 2017 16:30:56 +0300, Aleksey Makarov wrote:
> This series adds support for IEEE 1588 Precision Time Protocol
> to Cavium ethernet driver.
>
> The first patch adds support for the Precision Time Protocol Clocks and
> Timestamping coprocessor (PTP) found on Cavium processors.
> It registers a new PTP clock in the PTP core and provides functions
> to use the counter in BGX, TNS, GTI, and NIC blocks.
>
> The second patch introduces support for the PTP protocol to the
> Cavium ThunderX ethernet driver.
Since this is PTP-related, would it make sense to CC Richard Cochran
on the next revision?
^ permalink raw reply
* Re: [PATCH net-next] net: stmmac: fix broken dma_interrupt handling for multi-queues
From: Niklas Cassel @ 2017-12-07 23:57 UTC (permalink / raw)
To: Joao.Pinto, Giuseppe Cavallaro, Alexandre Torgue, Jose.Abreu
Cc: netdev, linux-kernel
In-Reply-To: <20171207225610.15572-1-niklas.cassel@axis.com>
On Thu, Dec 07, 2017 at 11:56:10PM +0100, Niklas Cassel wrote:
> Since each DMA channel can be used for rx and tx simultaneously,
> the current code should probably be rewritten so that napi_struct is
> embedded in a new struct stmmac_channel.
> That way, stmmac_poll() can call stmmac_tx_clean() on just the tx queue
> where we got the IRQ, instead of looping through all tx queues.
> This is also how the xgbe driver does it (another driver for this IP).
Did anyone at Synopsys ever try this driver with a device tree
where num tx queues != num rx queues?
I know your hardware has 8 rx queues and 8 tx queues, but
that doesn't mean that you have to enable them all.
After fixing this crash, I'm still seeing tx timeouts with multi-queue
device trees. (At Axis we usually only enable 1 tx queue and 1 rx queue).
The multi-queue code seems a bit messy.. refactoring so that napi_struct
is in a struct stmmac_channel might help you guys with overall code
readability, since this would then actually match how the hardware works.
With the xgbe driver, xgbe_one_poll disable tx+rx irqs for a specific
channel, then calls futher function only with that specific channel.
With the stmmac driver, there is no connection between napi_struct
and tx. Disable irqs for tx? stmmac_poll loops through all tx queues :)
^ permalink raw reply
* Re: [PATCH net-next v2 1/5] net: Introduce NETIF_F_GRO_HW.
From: Michael Chan @ 2017-12-08 0:05 UTC (permalink / raw)
To: Alexander Duyck
Cc: David Miller, Netdev, Andrew Gospodarek, Ariel Elior,
everest-linux-l2
In-Reply-To: <CAKgT0UeKTW8ued4NFcbqiSOy5xyhPKAcZUtb-nUmMC13uHO-Yw@mail.gmail.com>
On Thu, Dec 7, 2017 at 3:35 PM, Alexander Duyck
<alexander.duyck@gmail.com> wrote:
> On Thu, Dec 7, 2017 at 3:17 PM, Michael Chan <michael.chan@broadcom.com> wrote:
>> I don't get this. I don't see how TSO is related.
>
> It isn't. That is the point. If I change ANY feature it will trigger
> fix_features to get called. It will then see we have GRO_HW and LRO
> since we have one interface that supports one and one that supports
> another. It will trigger this code and cause LRO to be disabled which
> then will be propagated down.
I see. But this won't happen. Because the bonding driver is not
advertising NETIF_F_GRO_HW in its hw_features. It is not advertising
NETIF_F_GRO either but I think it gets added automatically since it is
a software feature. So LRO won't get disabled on the bond when a
unrelated feature is changed.
But I think I see your point. I can make it so that it is up to
individual driver's .ndo_fix_features() to drop LRO/GRO_HW as it sees
fit, instead of doing it in the common netdev_fix_features(). That
way, it is more flexible at least.
>
>>> That
>>> is a bad behavior and shouldn't happen. In addition I would want to be
>>> able to disable GRO_HW from the bond should I encounter a buggy
>>> implementation of the GRO hardware offload at some point in the
>>> future. I don't like it being tied so closely with GRO since all it
>>> takes is one hardware failure and then we are dealing with people
>>> disabling GRO due to reports of it being buggy instead of it being
>>> tied specifically to GRO_HW.
>>>
>>
>> Today, GRO, RXCSUM, NTUPLE, etc on a bond do not get propagated. You
>> can propose and make them propagate if you want.
>
> Or you can fix your patches so you take it into account now instead of
> putting things in a broken state and asking others to fix it.
I don't think that things are necessarily broken today. LRO truly
needs to be propagated. It's debatable whether other features like
GRO/RXCSUM/NTUPLE should be centrally set by the upper device or not.
>
>> So GRO_HW just naturally follows GRO since it is a true subset of it.
>
> Right, and I am saying you have exposed a bug. If I don't want GRO on
> the bond it should be propagated down. It doesn't make sense to allow
> lower devices to assemble frames when the bond doesn't want them and
> GSO won't kick in before it gets to the bond.
GRO kicks in at the lower device before it gets to the bond if the
lower device calls napi_gro_receive() and GRO is enabled.
^ permalink raw reply
* [PATCH v6 net-next,mips 0/7] Cavium OCTEON-III network driver.
From: David Daney @ 2017-12-08 0:09 UTC (permalink / raw)
To: linux-mips-6z/3iImG2C8G8FEW9MqTrA, ralf-6z/3iImG2C8G8FEW9MqTrA,
James Hogan, netdev-u79uwXL29TY76Z2rM5mHXA, David S. Miller,
Rob Herring, Mark Rutland
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Steven J. Hill,
devicetree-u79uwXL29TY76Z2rM5mHXA, Andrew Lunn, Florian Fainelli,
Philippe Ombredanne, David Daney
We are adding the Cavium OCTEON-III network driver. But since
interacting with the input and output queues is done via special CPU
local memory, we also need to add support to the MIPS/Octeon
architecture code. Aren't SoCs nice in this way?
The first five patches add the SoC support needed by the driver, the
last two add the driver and an entry in MAINTAINERS.
Since these touch several subsystems (mips, netdev), I would
propose merging via netdev, but defer to the maintainers if they think
something else would work better.
A separate pull request was recently done by Steven Hill for the
firmware required by the driver.
Changes in v6:
o Added back cleanup patch for previous generation SoC "staging"
driver, as Greg K-H acked it.
o Moved FPA driver to drivers/net/ethernet/cavium/octeon as it is
currently only used by the octeon3-ethernet driver.
o Many code formatting fixes as noted by davem.
Changes in v5:
o Removed cleanup patch for previous generation SoC "staging" driver,
as it will be sent as a follow-on.
o Fixed kernel doc formatting in all patches.
o Removed redundant licensing text boilerplate.
o Reviewed-by: header added to 2/7.
o Rewrote locking code in 3/7 to eliminate inline asm.
Changes in v4:
o Use phy_print_status() instead of open coding the equivalent.
o Print warning on phy mode mismatch.
o Improve dt-bindings and add Acked-by.
Changes in v3:
o Fix PKI (RX path) initialization to work with little endian kernel.
Changes in v2:
o Cleanup and use of standard bindings in the device tree bindings
document.
o Added (hopefully) clarifying comments about several OCTEON
architectural peculiarities.
o Removed unused testing code from the driver.
o Removed some module parameters that already default to the proper
values.
o KConfig cleanup, including testing on x86_64, arm64 and mips.
o Fixed breakage to the driver for previous generation of OCTEON SoCs (in
the staging directory still).
o Verified bisectability of the patch set.
Carlos Munoz (4):
dt-bindings: Add Cavium Octeon Common Ethernet Interface.
MIPS: Octeon: Enable LMTDMA/LMTST operations.
MIPS: Octeon: Add a global resource manager.
netdev: octeon-ethernet: Add Cavium Octeon III support.
David Daney (3):
MIPS: Octeon: Automatically provision CVMSEG space.
staging: octeon: Remove USE_ASYNC_IOBDMA macro.
MAINTAINERS: Add entry for
drivers/net/ethernet/cavium/octeon/octeon3-*
.../devicetree/bindings/net/cavium-bgx.txt | 61 +
MAINTAINERS | 6 +
arch/mips/cavium-octeon/Kconfig | 27 +-
arch/mips/cavium-octeon/Makefile | 1 +
arch/mips/cavium-octeon/resource-mgr.c | 351 ++++
arch/mips/cavium-octeon/setup.c | 22 +-
.../asm/mach-cavium-octeon/kernel-entry-init.h | 20 +-
arch/mips/include/asm/mipsregs.h | 2 +
arch/mips/include/asm/octeon/octeon.h | 32 +-
arch/mips/include/asm/processor.h | 2 +-
arch/mips/kernel/octeon_switch.S | 2 -
arch/mips/mm/tlbex.c | 29 +-
drivers/net/ethernet/cavium/Kconfig | 59 +-
drivers/net/ethernet/cavium/octeon/Makefile | 7 +
.../net/ethernet/cavium/octeon/octeon3-bgx-nexus.c | 417 ++++
.../net/ethernet/cavium/octeon/octeon3-bgx-port.c | 2018 +++++++++++++++++++
drivers/net/ethernet/cavium/octeon/octeon3-core.c | 2079 ++++++++++++++++++++
drivers/net/ethernet/cavium/octeon/octeon3-fpa.c | 358 ++++
drivers/net/ethernet/cavium/octeon/octeon3-pki.c | 823 ++++++++
drivers/net/ethernet/cavium/octeon/octeon3-pko.c | 1688 ++++++++++++++++
drivers/net/ethernet/cavium/octeon/octeon3-sso.c | 301 +++
drivers/net/ethernet/cavium/octeon/octeon3.h | 430 ++++
drivers/staging/octeon/ethernet-defines.h | 6 -
drivers/staging/octeon/ethernet-rx.c | 25 +-
drivers/staging/octeon/ethernet-tx.c | 85 +-
25 files changed, 8709 insertions(+), 142 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/cavium-bgx.txt
create mode 100644 arch/mips/cavium-octeon/resource-mgr.c
create mode 100644 drivers/net/ethernet/cavium/octeon/octeon3-bgx-nexus.c
create mode 100644 drivers/net/ethernet/cavium/octeon/octeon3-bgx-port.c
create mode 100644 drivers/net/ethernet/cavium/octeon/octeon3-core.c
create mode 100644 drivers/net/ethernet/cavium/octeon/octeon3-fpa.c
create mode 100644 drivers/net/ethernet/cavium/octeon/octeon3-pki.c
create mode 100644 drivers/net/ethernet/cavium/octeon/octeon3-pko.c
create mode 100644 drivers/net/ethernet/cavium/octeon/octeon3-sso.c
create mode 100644 drivers/net/ethernet/cavium/octeon/octeon3.h
--
2.14.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v6 net-next,mips 1/7] dt-bindings: Add Cavium Octeon Common Ethernet Interface.
From: David Daney @ 2017-12-08 0:09 UTC (permalink / raw)
To: linux-mips, ralf, James Hogan, netdev, David S. Miller,
Rob Herring, Mark Rutland
Cc: linux-kernel, Steven J. Hill, devicetree, Andrew Lunn,
Florian Fainelli, Philippe Ombredanne, Carlos Munoz,
Steven J . Hill, David Daney
In-Reply-To: <20171208000934.6554-1-david.daney@cavium.com>
From: Carlos Munoz <cmunoz@cavium.com>
Add bindings for Common Ethernet Interface (BGX) block.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Carlos Munoz <cmunoz@cavium.com>
Signed-off-by: Steven J. Hill <Steven.Hill@cavium.com>
Signed-off-by: David Daney <david.daney@cavium.com>
---
.../devicetree/bindings/net/cavium-bgx.txt | 61 ++++++++++++++++++++++
1 file changed, 61 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/cavium-bgx.txt
diff --git a/Documentation/devicetree/bindings/net/cavium-bgx.txt b/Documentation/devicetree/bindings/net/cavium-bgx.txt
new file mode 100644
index 000000000000..830c5f08dddd
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/cavium-bgx.txt
@@ -0,0 +1,61 @@
+* Common Ethernet Interface (BGX) block
+
+Properties:
+
+- compatible: "cavium,octeon-7890-bgx": Compatibility with all cn7xxx SOCs.
+
+- reg: The base address of the BGX block.
+
+- #address-cells: Must be <1>.
+
+- #size-cells: Must be <0>. BGX addresses have no size component.
+
+A BGX block has several children, each representing an Ethernet
+interface.
+
+
+* Ethernet Interface (BGX port) connects to PKI/PKO
+
+Properties:
+
+- compatible: "cavium,octeon-7890-bgx-port": Compatibility with all
+ cn7xxx SOCs.
+
+ "cavium,octeon-7360-xcv": Compatibility with cn73xx SOCs
+ for RGMII.
+
+- reg: The index of the interface within the BGX block.
+
+Optional properties:
+
+- local-mac-address: Mac address for the interface.
+
+- phy-handle: phandle to the phy node connected to the interface.
+
+- phy-mode: described in ethernet.txt.
+
+- fixed-link: described in fixed-link.txt.
+
+Example:
+
+ ethernet-mac-nexus@11800e0000000 {
+ compatible = "cavium,octeon-7890-bgx";
+ reg = <0x00011800 0xe0000000 0x00000000 0x01000000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet@0 {
+ compatible = "cavium,octeon-7360-xcv";
+ reg = <0>;
+ local-mac-address = [ 00 01 23 45 67 89 ];
+ phy-handle = <&phy3>;
+ phy-mode = "rgmii-rxid"
+ };
+ ethernet@1 {
+ compatible = "cavium,octeon-7890-bgx-port";
+ reg = <1>;
+ local-mac-address = [ 00 01 23 45 67 8a ];
+ phy-handle = <&phy4>;
+ phy-mode = "sgmii"
+ };
+ };
--
2.14.3
^ permalink raw reply related
* [PATCH v6 net-next,mips 2/7] MIPS: Octeon: Enable LMTDMA/LMTST operations.
From: David Daney @ 2017-12-08 0:09 UTC (permalink / raw)
To: linux-mips, ralf, James Hogan, netdev, David S. Miller,
Rob Herring, Mark Rutland
Cc: linux-kernel, Steven J. Hill, devicetree, Andrew Lunn,
Florian Fainelli, Philippe Ombredanne, Carlos Munoz,
Steven J . Hill, David Daney
In-Reply-To: <20171208000934.6554-1-david.daney@cavium.com>
From: Carlos Munoz <cmunoz@cavium.com>
LMTDMA/LMTST operations move data between cores and I/O devices:
* LMTST operations can send an address and a variable length
(up to 128 bytes) of data to an I/O device.
* LMTDMA operations can send an address and a variable length
(up to 128) of data to the I/O device and then return a
variable length (up to 128 bytes) response from the I/O device.
For both LMTST and LMTDMA, the data sent to the device is first stored
in the CVMSEG core local memory cache line indexed by
CVMMEMCTL[LMTLINE], the data is then atomically transmitted to the
device with a store to the CVMSEG LMTDMA trigger location.
Reviewed-by: James Hogan <jhogan@kernel.org>
Signed-off-by: Carlos Munoz <cmunoz@cavium.com>
Signed-off-by: Steven J. Hill <Steven.Hill@cavium.com>
Signed-off-by: David Daney <david.daney@cavium.com>
---
arch/mips/cavium-octeon/setup.c | 6 ++++++
arch/mips/include/asm/octeon/octeon.h | 12 ++++++++++--
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/mips/cavium-octeon/setup.c b/arch/mips/cavium-octeon/setup.c
index a8034d0dcade..99e6a68bc652 100644
--- a/arch/mips/cavium-octeon/setup.c
+++ b/arch/mips/cavium-octeon/setup.c
@@ -609,6 +609,12 @@ void octeon_user_io_init(void)
#else
cvmmemctl.s.cvmsegenak = 0;
#endif
+ if (OCTEON_IS_OCTEON3()) {
+ /* Enable LMTDMA */
+ cvmmemctl.s.lmtena = 1;
+ /* Scratch line to use for LMT operation */
+ cvmmemctl.s.lmtline = 2;
+ }
/* R/W If set, CVMSEG is available for loads/stores in
* supervisor mode. */
cvmmemctl.s.cvmsegenas = 0;
diff --git a/arch/mips/include/asm/octeon/octeon.h b/arch/mips/include/asm/octeon/octeon.h
index c99c4b6a79f4..92a17d67c1fa 100644
--- a/arch/mips/include/asm/octeon/octeon.h
+++ b/arch/mips/include/asm/octeon/octeon.h
@@ -179,7 +179,15 @@ union octeon_cvmemctl {
/* RO 1 = BIST fail, 0 = BIST pass */
__BITFIELD_FIELD(uint64_t wbfbist:1,
/* Reserved */
- __BITFIELD_FIELD(uint64_t reserved:17,
+ __BITFIELD_FIELD(uint64_t reserved_52_57:6,
+ /* When set, LMTDMA/LMTST operations are permitted */
+ __BITFIELD_FIELD(uint64_t lmtena:1,
+ /* Selects the CVMSEG LM cacheline used by LMTDMA
+ * LMTST and wide atomic store operations.
+ */
+ __BITFIELD_FIELD(uint64_t lmtline:6,
+ /* Reserved */
+ __BITFIELD_FIELD(uint64_t reserved_41_44:4,
/* OCTEON II - TLB replacement policy: 0 = bitmask LRU; 1 = NLU.
* This field selects between the TLB replacement policies:
* bitmask LRU or NLU. Bitmask LRU maintains a mask of
@@ -275,7 +283,7 @@ union octeon_cvmemctl {
/* R/W Size of local memory in cache blocks, 54 (6912
* bytes) is max legal value. */
__BITFIELD_FIELD(uint64_t lmemsz:6,
- ;)))))))))))))))))))))))))))))))))
+ ;))))))))))))))))))))))))))))))))))))
} s;
};
--
2.14.3
^ permalink raw reply related
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