* [PATCH] ucc_geth: Reset BQL queue when stopping device
From: Mathias Thore @ 2019-01-28 9:07 UTC (permalink / raw)
To: leoyang.li, netdev, linuxppc-dev, david.gounaris,
joakim.tjernlund
Cc: Mathias Thore
After a timeout event caused by for example a broadcast storm, when
the MAC and PHY are reset, the BQL TX queue needs to be reset as
well. Otherwise, the device will exhibit severe performance issues
even after the storm has ended.
Co-authored-by: David Gounaris <david.gounaris@infinera.com>
Signed-off-by: Mathias Thore <mathias.thore@infinera.com>
---
drivers/net/ethernet/freescale/ucc_geth.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/freescale/ucc_geth.c b/drivers/net/ethernet/freescale/ucc_geth.c
index c3d539e209ed..eb3e65e8868f 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.c
+++ b/drivers/net/ethernet/freescale/ucc_geth.c
@@ -1879,6 +1879,8 @@ static void ucc_geth_free_tx(struct ucc_geth_private *ugeth)
u16 i, j;
u8 __iomem *bd;
+ netdev_reset_queue(ugeth->ndev);
+
ug_info = ugeth->ug_info;
uf_info = &ug_info->uf_info;
--
2.19.2
^ permalink raw reply related
* Re: [PATCH 1/7] sh_eth: rename sh_eth_cpu_data::hw_checksum
From: Geert Uytterhoeven @ 2019-01-28 9:21 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: netdev, David S. Miller, Linux-Renesas, Linux-sh list
In-Reply-To: <b73763ac-5909-c95e-efa5-9d44fba9b9bf@cogentembedded.com>
Hi Sergei,
Thanks for your patch!
On Sun, Jan 27, 2019 at 6:40 PM Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Commit 62e04b7e0e3c ("sh_eth: rename 'sh_eth_cpu_data::hw_crc'") renamed
> the field to 'hw_checksum' for the Ether DMAC "intelligent checksum",
> however some Ether MACs implement a simpler checksumming scheme, so that
> name now seems misleading. Rename that filed to 'csmr' as the "intelligent
> checkmum" is always controlled by the CSMR register.
checksum
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Apart from that:
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> --- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
> +++ net-next/drivers/net/ethernet/renesas/sh_eth.c
> @@ -793,7 +793,7 @@ static struct sh_eth_cpu_data r8a77980_d
> .no_trimd = 1,
> .no_ade = 1,
> .xdfar_rw = 1,
> - .hw_checksum = 1,
> + .csmr = 1,
Interestingly, I cannot find the CSMR register in the R-Car Gen3 docs?
Not introduced by this patch, though.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: bpf memory model. Was: [PATCH v4 bpf-next 1/9] bpf: introduce bpf_spin_lock
From: Peter Zijlstra @ 2019-01-28 9:24 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Alexei Starovoitov, davem, daniel, jakub.kicinski, netdev,
kernel-team, mingo, will.deacon, Paul McKenney, jannh
In-Reply-To: <20190126001725.roqqfrpysyljqiqx@ast-mbp.dhcp.thefacebook.com>
On Fri, Jan 25, 2019 at 04:17:26PM -0800, Alexei Starovoitov wrote:
> On Fri, Jan 25, 2019 at 11:23:12AM +0100, Peter Zijlstra wrote:
> > On Thu, Jan 24, 2019 at 03:58:59PM -0800, Alexei Starovoitov wrote:
> > > On Thu, Jan 24, 2019 at 07:01:09PM +0100, Peter Zijlstra wrote:
> >
> > > > And this would again be the moment where I go pester you about the BPF
> > > > memory model :-)
> > >
> > > hehe :)
> > > How do you propose to define it in a way that it applies to all archs
> > > and yet doesn't penalize x86 ?
> > > "Assume minimum execution ordering model" the way kernel does
> > > unfortunately is not usable, since bpf doesn't have a luxury
> > > of using nice #defines that convert into nops on x86.
> >
> > Why not? Surely the JIT can fix it up? That is, suppose you were to have
> > smp_rmb() as a eBPF instruction then the JIT (which knows what
> > architecture it is targeting) can simply avoid emitting instructions for
> > it.
>
> I'm all for adding new instructions that solve real use cases.
> imo bpf_spin_lock() is the first step in helping with concurrency.
> At plumbers conference we agreed to add new sync_fetch_and_add()
> and xchg() instructions. That's a second step.
> smp_rmb/wmb/mb should be added as well.
> JITs will patch them depending on architecture.
>
> What I want to avoid is to define the whole execution ordering model upfront.
> We cannot say that BPF ISA is weakly ordered like alpha.
> Most of the bpf progs are written and running on x86. We shouldn't
> twist bpf developer's arm by artificially relaxing memory model.
> BPF memory model is equal to memory model of underlying architecture.
> What we can do is to make it bpf progs a bit more portable with
> smp_rmb instructions, but we must not force weak execution on the developer.
Well, I agree with only introducing bits you actually need, and my
smp_rmb() example might have been poorly chosen, smp_load_acquire() /
smp_store_release() might have been a far more useful example.
But I disagree with the last part; we have to pick a model now;
otherwise you'll pain yourself into a corner.
Also; Alpha isn't very relevant these days; however ARM64 does seem to
be gaining a lot of attention and that is very much a weak architecture.
Adding strongly ordered assumptions to BPF now, will penalize them in
the long run.
> > Similarly; could something like this not also help with the spinlock
> > thing? Use that generic test-and-set thing for the interpreter, but
> > provide a better implementation in the JIT?
>
> May be eventually. We can add cmpxchg insn, but the verifier still
> doesn't support loops. We made a lot of progress in bounded loop research
> over the last 2 years, but loops in bpf are still a year away.
> We considered adding 'bpf_spin_lock' as a new instruction instead of helper call,
> but that approach has a lot of negatives, so we went with the helper.
Ah, but the loop won't be in the BPF program itself. The BPF program
would only have had the BPF_SPIN_LOCK instruction, the JIT them emits
code similar to queued_spin_lock()/queued_spin_unlock() (or calls to
out-of-line versions of them).
There isn't anything that mandates the JIT uses the exact same locking
routines the interpreter does, is there?
^ permalink raw reply
* Re: [RFC PATCH 2/6] net/sched: flower: add support for matching on ConnTrack
From: Simon Horman @ 2019-01-28 9:44 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: Guy Shattah, Aaron Conole, John Hurley, Justin Pettit,
Gregory Rose, Eelco Chaudron, Flavio Leitner, Florian Westphal,
Jiri Pirko, Rashid Khan, Sushil Kulkarni, Andy Gospodarek,
Roi Dayan, Yossi Kuperman, Or Gerlitz, Rony Efraim,
davem@davemloft.net, netdev
In-Reply-To: <20190126155201.GI10660@localhost.localdomain>
On Sat, Jan 26, 2019 at 01:52:01PM -0200, Marcelo Ricardo Leitner wrote:
> On Fri, Jan 25, 2019 at 02:37:13PM +0100, Simon Horman wrote:
> > Hi Marcelo,
> >
> > On Fri, Jan 25, 2019 at 12:32:31AM -0200, Marcelo Ricardo Leitner wrote:
> > > Hook on flow dissector's new interface on ConnTrack from previous patch.
> > >
> > > Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com>
> > > ---
> > > include/uapi/linux/pkt_cls.h | 9 +++++++++
> > > net/sched/cls_flower.c | 33 +++++++++++++++++++++++++++++++++
> > > 2 files changed, 42 insertions(+)
> > >
> > > diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
> > > index 95d0db2a8350dffb1dd20816591f3b179913fb2e..ba1f3bc01b2fdfd810e37a2b3853a1da1f838acf 100644
> > > --- a/include/uapi/linux/pkt_cls.h
> > > +++ b/include/uapi/linux/pkt_cls.h
> > > @@ -490,6 +490,15 @@ enum {
> > > TCA_FLOWER_KEY_PORT_DST_MIN, /* be16 */
> > > TCA_FLOWER_KEY_PORT_DST_MAX, /* be16 */
> > >
> > > + TCA_FLOWER_KEY_CT_ZONE, /* u16 */
> > > + TCA_FLOWER_KEY_CT_ZONE_MASK, /* u16 */
> > > + TCA_FLOWER_KEY_CT_STATE, /* u8 */
> > > + TCA_FLOWER_KEY_CT_STATE_MASK, /* u8 */
> >
> > With the corresponding flow dissector patch this API is
> > exposing the contents of an instance of enum ip_conntrack_info
> > as an ABI for conntrack state.
> >
> > I believe (after getting similar review for my geneve options macthing
> > patches for flower) that this exposes implementation details as an ABI
> > to a degree that is not desirable.
> >
> > My suggested would be to define, say in the form of named bits,
> > an ABI, that describes the state information that is exposed.
> > These bits may not correspond directly to the implementation of
> > ip_conntrack_info.
> >
> > I think there should also be some consideration of if a mask makes
> > sense for the state as, f.e. in the implementation of enum
> > ip_conntrack_info not all bit combinations are valid.
>
> Right. ct_state must be handled differently. For conntrack it is a
> linear enum and as we want to be able to OR match, we will have to
> convert the states in a bitfield as you were saying or so.
>
> I don't think the representation above wouldn't change, though: we have
> 8 bits wrapped under a u8. What would change is how we deal with it.
>
> If iproute tc is able to parse the cmdline and set a corresponding bit
> for each state, the flower-side of flow dissector here should be
> mostly fine (need to consider the invalid bits as you mentioned, as
> part of sanity checking).
> Then just need to change on how flow dissector is reading ct_state
> from the packet.
I'm not entirely opposed to a KABI which defines bits of
TCA_FLOWER_KEY_CT_STATE in such a way that they match exactly
the current implementation of enum ip_conntrack_info (though I do suspect
that a better representation is possible, for some value of better).
But, on the other hand, I am not comfortable in simply sating that
TCA_FLOWER_KEY_CT_STATE is the same as enum ip_conntrack_info, because
that exposes an internal implementation detail which may change.
> Is your comment only related to ct_state or other fields too? I'm
> thinking only ct_state.
Sorry that I wasn't clear, I was only referring to ct_state.
> > > + TCA_FLOWER_KEY_CT_MARK, /* u32 */
> > > + TCA_FLOWER_KEY_CT_MARK_MASK, /* u32 */
> > > + TCA_FLOWER_KEY_CT_LABEL, /* 128 bits */
> > > + TCA_FLOWER_KEY_CT_LABEL_MASK, /* 128 bits */
> > > +
> > > __TCA_FLOWER_MAX,
> > > };
> >
> > ...
> >
^ permalink raw reply
* Re: [PATCH net-next 00/24] sctp: support SCTP_FUTURE/CURRENT/ALL_ASSOC
From: Neil Horman @ 2019-01-28 9:44 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, linux-sctp, Marcelo Ricardo Leitner, davem
In-Reply-To: <cover.1548659198.git.lucien.xin@gmail.com>
On Mon, Jan 28, 2019 at 03:08:22PM +0800, Xin Long wrote:
> This patchset adds the support for 3 assoc_id constants: SCTP_FUTURE_ASSOC
> SCTP_CURRENT_ASSOC, SCTP_ALL_ASSOC, described in rfc6458#section-7.2:
>
> All socket options set on a one-to-one style listening socket also
> apply to all future accepted sockets. For one-to-many style sockets,
> often a socket option will pass a structure that includes an assoc_id
> field. This field can be filled with the association identifier of a
> particular association and unless otherwise specified can be filled
> with one of the following constants:
>
> SCTP_FUTURE_ASSOC: Specifies that only future associations created
> after this socket option will be affected by this call.
>
> SCTP_CURRENT_ASSOC: Specifies that only currently existing
> associations will be affected by this call, and future
> associations will still receive the previous default value.
>
> SCTP_ALL_ASSOC: Specifies that all current and future associations
> will be affected by this call.
>
> The functions for many other sockopts that use assoc_id also need to be
> updated accordingly.
>
> Xin Long (24):
> sctp: introduce SCTP_FUTURE/CURRENT/ALL_ASSOC
> sctp: use SCTP_FUTURE_ASSOC for SCTP_PEER_ADDR_PARAMS sockopt
> sctp: use SCTP_FUTURE_ASSOC for SCTP_RTOINFO sockopt
> sctp: use SCTP_FUTURE_ASSOC for SCTP_ASSOCINFO sockopt
> sctp: use SCTP_FUTURE_ASSOC for SCTP_MAXSEG sockopt
> sctp: use SCTP_FUTURE_ASSOC for SCTP_LOCAL_AUTH_CHUNKS sockopt
> sctp: add SCTP_FUTURE_ASSOC for SCTP_PEER_ADDR_THLDS sockopt
> sctp: use SCTP_FUTURE_ASSOC for SCTP_PR_SUPPORTED sockopt
> sctp: use SCTP_FUTURE_ASSOC for SCTP_RECONFIG_SUPPORTED sockopt
> sctp: use SCTP_FUTURE_ASSOC for SCTP_INTERLEAVING_SUPPORTED sockopt
> sctp: add SCTP_CURRENT_ASSOC for SCTP_STREAM_SCHEDULER_VALUE sockopt
> sctp: use SCTP_FUTURE_ASSOC and add SCTP_CURRENT_ASSOC for
> SCTP_DELAYED_SACK sockopt
> sctp: use SCTP_FUTURE_ASSOC and add SCTP_CURRENT_ASSOC for
> SCTP_DEFAULT_SEND_PARAM sockopt
> sctp: use SCTP_FUTURE_ASSOC and add SCTP_CURRENT_ASSOC for
> SCTP_DEFAULT_SNDINFO sockopt
> sctp: use SCTP_FUTURE_ASSOC and add SCTP_CURRENT_ASSOC for
> SCTP_CONTEXT sockopt
> sctp: use SCTP_FUTURE_ASSOC and add SCTP_CURRENT_ASSOC for
> SCTP_MAX_BURST sockopt
> sctp: use SCTP_FUTURE_ASSOC and add SCTP_CURRENT_ASSOC for
> SCTP_AUTH_KEY sockopt
> sctp: use SCTP_FUTURE_ASSOC and add SCTP_CURRENT_ASSOC for
> SCTP_AUTH_ACTIVE_KEY sockopt
> sctp: use SCTP_FUTURE_ASSOC and add SCTP_CURRENT_ASSOC for
> SCTP_AUTH_DELETE_KEY sockopt
> sctp: use SCTP_FUTURE_ASSOC and add SCTP_CURRENT_ASSOC for
> SCTP_AUTH_DEACTIVATE_KEY sockopt
> sctp: use SCTP_FUTURE_ASSOC and add SCTP_CURRENT_ASSOC for
> SCTP_DEFAULT_PRINFO sockopt
> sctp: use SCTP_FUTURE_ASSOC and add SCTP_CURRENT_ASSOC for
> SCTP_ENABLE_STREAM_RESET sockopt
> sctp: use SCTP_FUTURE_ASSOC and add SCTP_CURRENT_ASSOC for SCTP_EVENT
> sockopt
> sctp: add SCTP_FUTURE_ASOC and SCTP_CURRENT_ASSOC for
> SCTP_STREAM_SCHEDULER sockopt
>
> include/net/sctp/structs.h | 4 +
> include/uapi/linux/sctp.h | 4 +
> net/sctp/associola.c | 9 +-
> net/sctp/outqueue.c | 2 +-
> net/sctp/socket.c | 773 ++++++++++++++++++++++++++++++---------------
> 5 files changed, 525 insertions(+), 267 deletions(-)
>
> --
> 2.1.0
>
>
Sorry, I'm traveling at the moment, but I'll review this as soon as I'm back on the ground
Neil
^ permalink raw reply
* Re: [PATCH] ucc_geth: Reset BQL queue when stopping device
From: Christophe Leroy @ 2019-01-28 9:48 UTC (permalink / raw)
To: Mathias Thore, leoyang.li, netdev, linuxppc-dev, david.gounaris,
joakim.tjernlund
In-Reply-To: <20190128090747.15851-1-mathias.thore@infinera.com>
Hi,
Le 28/01/2019 à 10:07, Mathias Thore a écrit :
> After a timeout event caused by for example a broadcast storm, when
> the MAC and PHY are reset, the BQL TX queue needs to be reset as
> well. Otherwise, the device will exhibit severe performance issues
> even after the storm has ended.
What are the symptomns ?
Is this reset needed on any network driver in that case, or is it
something particular for the ucc_geth ?
For instance, the freescale fs_enet doesn't have that reset. Should it
have it too ?
Christophe
>
> Co-authored-by: David Gounaris <david.gounaris@infinera.com>
> Signed-off-by: Mathias Thore <mathias.thore@infinera.com>
> ---
> drivers/net/ethernet/freescale/ucc_geth.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/ethernet/freescale/ucc_geth.c b/drivers/net/ethernet/freescale/ucc_geth.c
> index c3d539e209ed..eb3e65e8868f 100644
> --- a/drivers/net/ethernet/freescale/ucc_geth.c
> +++ b/drivers/net/ethernet/freescale/ucc_geth.c
> @@ -1879,6 +1879,8 @@ static void ucc_geth_free_tx(struct ucc_geth_private *ugeth)
> u16 i, j;
> u8 __iomem *bd;
>
> + netdev_reset_queue(ugeth->ndev);
> +
> ug_info = ugeth->ug_info;
> uf_info = &ug_info->uf_info;
>
>
^ permalink raw reply
* Re: [PATCH] netfilter: ipt_CLUSTERIP: fix warning unused variable cn
From: Pablo Neira Ayuso @ 2019-01-28 9:51 UTC (permalink / raw)
To: Anders Roxell
Cc: kadlec, fw, davem, kuznet, yoshfuji, netfilter-devel, coreteam,
netdev, linux-kernel
In-Reply-To: <20190123114811.25388-1-anders.roxell@linaro.org>
On Wed, Jan 23, 2019 at 12:48:11PM +0100, Anders Roxell wrote:
> When CONFIG_PROC_FS isn't set the variable cn isn't used.
>
> net/ipv4/netfilter/ipt_CLUSTERIP.c: In function ‘clusterip_net_exit’:
> net/ipv4/netfilter/ipt_CLUSTERIP.c:849:24: warning: unused variable ‘cn’ [-Wunused-variable]
> struct clusterip_net *cn = clusterip_pernet(net);
> ^~
>
> Rework so the variable 'cn' is declared inside "#ifdef CONFIG_PROC_FS".
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net v2 0/2] fix glitch in IPVS /proc handlers
From: Pablo Neira Ayuso @ 2019-01-28 10:17 UTC (permalink / raw)
To: Matteo Croce
Cc: Wensong Zhang, Simon Horman, Julian Anastasov, lvs-devel, netdev,
Jozsef Kadlecsik, Florian Westphal, netfilter-devel, Eric Dumazet
In-Reply-To: <20180731160333.12215-1-mcroce@redhat.com>
On Tue, Jul 31, 2018 at 06:03:31PM +0200, Matteo Croce wrote:
> Fix a bug which shows negative values in IPVS /proc handlers.
> Also add an helper function to calculate a time delta
Series applied, thanks Matteo.
^ permalink raw reply
* Re: [Patch nf-next] nf_conntrack: fix error path in nf_conntrack_pernet_init()
From: Pablo Neira Ayuso @ 2019-01-28 10:18 UTC (permalink / raw)
To: Cong Wang
Cc: netdev, netfilter-devel, syzbot+fcee88b2d87f0539dfe9,
Jozsef Kadlecsik, Florian Westphal
In-Reply-To: <20190123205857.8107-1-xiyou.wangcong@gmail.com>
On Wed, Jan 23, 2019 at 12:58:57PM -0800, Cong Wang wrote:
> When nf_ct_netns_get() fails, it should clean up itself,
> its caller doesn't need to call nf_conntrack_fini_net().
>
> nf_conntrack_init_net() is called after registering sysctl
> and proc, so its cleanup function should be called before
> unregistering sysctl and proc.
Applies, thanks.
^ permalink raw reply
* Re: [PATCH 1/7] sh_eth: rename sh_eth_cpu_data::hw_checksum
From: Sergei Shtylyov @ 2019-01-28 11:08 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: netdev, David S. Miller, Linux-Renesas, Linux-sh list
In-Reply-To: <CAMuHMdUYH-UzmiMv6LUT=R3gmHSF7LvcaDXszUixtAeXgjTr_Q@mail.gmail.com>
On 01/28/2019 12:21 PM, Geert Uytterhoeven wrote:
> On Sun, Jan 27, 2019 at 6:40 PM Sergei Shtylyov
> <sergei.shtylyov@cogentembedded.com> wrote:
>> Commit 62e04b7e0e3c ("sh_eth: rename 'sh_eth_cpu_data::hw_crc'") renamed
>> the field to 'hw_checksum' for the Ether DMAC "intelligent checksum",
>> however some Ether MACs implement a simpler checksumming scheme, so that
>> name now seems misleading. Rename that filed to 'csmr' as the "intelligent
>> checkmum" is always controlled by the CSMR register.
>
> checksum
Oops! Do I need to repost?
>
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> Apart from that:
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
>> --- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
>> +++ net-next/drivers/net/ethernet/renesas/sh_eth.c
>
>> @@ -793,7 +793,7 @@ static struct sh_eth_cpu_data r8a77980_d
>> .no_trimd = 1,
>> .no_ade = 1,
>> .xdfar_rw = 1,
>> - .hw_checksum = 1,
>> + .csmr = 1,
>
> Interestingly, I cannot find the CSMR register in the R-Car Gen3 docs?
Me niether... But if you remove that flag, the driver stops working due to
not doing >>= 16 in sh_eth_rx() anymore. Go figure... :-)
> Not introduced by this patch, though.
Yep.
> Gr{oetje,eeting}s,
>
> Geert
MBR, Sergei
^ permalink raw reply
* r8169 Driver - Poor Network Performance Since Kernel 4.19
From: Peter Ceiley @ 2019-01-28 11:13 UTC (permalink / raw)
To: Realtek linux nic maintainers, Heiner Kallweit; +Cc: netdev
Hi,
I have been experiencing very poor network performance since Kernel
4.19 and I'm confident it's related to the r8169 driver.
I have no issue with kernel versions 4.18 and prior. I am experiencing
this issue in kernels 4.19 and 4.20 (currently running/testing with
4.20.4 & 4.19.18).
If someone could guide me in the right direction, I'm happy to help
troubleshoot this issue. Note that I have been keeping an eye on one
issue related to loading of the PHY driver, however, my symptoms
differ in that I still have a network connection. I have attempted to
reload the driver on a running system, but this does not improve the
situation.
Using the proprietary r8168 driver returns my device to proper working order.
lshw shows:
description: Ethernet interface
product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
vendor: Realtek Semiconductor Co., Ltd.
physical id: 0
bus info: pci@0000:03:00.0
logical name: enp3s0
version: 0c
serial:
size: 1Gbit/s
capacity: 1Gbit/s
width: 64 bits
clock: 33MHz
capabilities: pm msi pciexpress msix vpd bus_master cap_list
ethernet physical tp aui bnc mii fibre 10bt 10bt-fd 100bt 100bt-fd
1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=r8169
duplex=full firmware=rtl8168g-2_0.0.1 02/06/13 ip=192.168.1.25
latency=0 link=yes multicast=yes port=MII speed=1Gbit/s
resources: irq:19 ioport:d000(size=256)
memory:f7b00000-f7b00fff memory:f2100000-f2103fff
Kind Regards,
Peter.
^ permalink raw reply
* [PATCH] ipconfig: make the wait for carrier timeout configurable
From: Martin Kepplinger @ 2019-01-28 11:30 UTC (permalink / raw)
To: davem, kuznet, yoshfuji, netdev
Cc: linux-kernel, Manfred Schlaegl, Martin Kepplinger
From: Manfred Schlaegl <manfred.schlaegl@ginzinger.com>
commit 3fb72f1e6e61 ("ipconfig wait for carrier") added a
"wait for carrier" policy, with a fixed worst case maximum wait
of two minutes.
This makes the wait for carrier timeout configurable (0 - 240 seconds).
The informative timeout messages introduced with
commit 5e404cd65860 ("ipconfig: add informative timeout messages while
waiting for carrier") were adapted. Message output is done in a fixed
interval of 20 seconds, just like before (240/12).
Signed-off-by: Manfred Schlaegl <manfred.schlaegl@ginzinger.com>
Signed-off-by: Martin Kepplinger <martin.kepplinger@ginzinger.com>
---
This is really just something we always set shorter on embedded devices
and don't understand why it isn't configurable :)
thanks
martin
net/ipv4/Kconfig | 11 +++++++++++
net/ipv4/ipconfig.c | 7 ++++---
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
index 32cae39cdff6..299c5dbbea97 100644
--- a/net/ipv4/Kconfig
+++ b/net/ipv4/Kconfig
@@ -113,6 +113,17 @@ config IP_PNP
on NFS" as well), because all other machines configure the network
in their startup scripts.
+config IP_PNP_CARRIER_TIMEOUT
+ int "Wait for carrier timeout (in seconds)"
+ default 120
+ range 0 240
+ depends on IP_PNP
+ help
+ This defines the timeout waiting for carrier in seconds before
+ continuing kernel startup.
+
+ Use the default if unsure.
+
config IP_PNP_DHCP
bool "IP: DHCP support"
depends on IP_PNP
diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index b9a9873c25c6..e8041c0c2b97 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -85,7 +85,8 @@
/* Define the friendly delay before and after opening net devices */
#define CONF_POST_OPEN 10 /* After opening: 10 msecs */
-#define CONF_CARRIER_TIMEOUT 120000 /* Wait for carrier timeout */
+/* Wait for carrier timeout */
+#define CONF_CARRIER_TIMEOUT (CONFIG_IP_PNP_CARRIER_TIMEOUT*1000)
/* Define the timeout for waiting for a DHCP/BOOTP/RARP reply */
#define CONF_OPEN_RETRIES 2 /* (Re)open devices twice */
@@ -268,7 +269,7 @@ static int __init ic_open_devs(void)
/* wait for a carrier on at least one device */
start = jiffies;
- next_msg = start + msecs_to_jiffies(CONF_CARRIER_TIMEOUT/12);
+ next_msg = start + msecs_to_jiffies(20000);
while (time_before(jiffies, start +
msecs_to_jiffies(CONF_CARRIER_TIMEOUT))) {
int wait, elapsed;
@@ -285,7 +286,7 @@ static int __init ic_open_devs(void)
elapsed = jiffies_to_msecs(jiffies - start);
wait = (CONF_CARRIER_TIMEOUT - elapsed + 500)/1000;
pr_info("Waiting up to %d more seconds for network.\n", wait);
- next_msg = jiffies + msecs_to_jiffies(CONF_CARRIER_TIMEOUT/12);
+ next_msg = jiffies + msecs_to_jiffies(20000);
}
have_carrier:
rtnl_unlock();
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 0/7] mlxsw: Misc updates
From: Ido Schimmel @ 2019-01-28 12:02 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: davem@davemloft.net, Jiri Pirko, mlxsw, Ido Schimmel
This patchset contains miscellaneous patches we gathered in our queue.
Some of them are dependencies of larger patchsets that I will submit
later this cycle.
Patches #1-#3 perform small non-functional changes in mlxsw.
Patch #4 adds more extended ack messages in mlxsw.
Patch #5 adds devlink parameters documentation for mlxsw. To be extended
with more parameters this cycle.
Patches #6-#7 perform small changes in forwarding selftests
infrastructure.
Ido Schimmel (2):
mlxsw: spectrum_switchdev: Add more extack messages
selftests: forwarding: Use OK instead of PASS in test output
Jiri Pirko (5):
mlxsw: spectrum_acl: Remove unnecessary arg on action_replace call
path
mlxsw: spectrum_acl: Move mr_ruleset and mr_rule structs
mlxsw: spectrum_acl: Fix rul/rule typo
Documentation: add devlink param file for mlxsw driver
selftests: net: forwarding: change devlink resource support checking
.../networking/devlink-params-mlxsw.txt | 2 ++
.../net/ethernet/mellanox/mlxsw/spectrum.h | 3 +-
.../mellanox/mlxsw/spectrum1_acl_tcam.c | 3 +-
.../mellanox/mlxsw/spectrum2_acl_tcam.c | 5 +---
.../ethernet/mellanox/mlxsw/spectrum_acl.c | 7 ++---
.../mellanox/mlxsw/spectrum_acl_atcam.c | 2 --
.../mellanox/mlxsw/spectrum_acl_ctcam.c | 1 -
.../mellanox/mlxsw/spectrum_acl_tcam.c | 29 +++++++++----------
.../mellanox/mlxsw/spectrum_acl_tcam.h | 5 +---
.../mellanox/mlxsw/spectrum_switchdev.c | 10 +++++--
.../selftests/net/forwarding/devlink_lib.sh | 2 +-
tools/testing/selftests/net/forwarding/lib.sh | 2 +-
12 files changed, 32 insertions(+), 39 deletions(-)
create mode 100644 Documentation/networking/devlink-params-mlxsw.txt
--
2.20.1
^ permalink raw reply
* [PATCH net-next 1/7] mlxsw: spectrum_acl: Remove unnecessary arg on action_replace call path
From: Ido Schimmel @ 2019-01-28 12:02 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: davem@davemloft.net, Jiri Pirko, mlxsw, Ido Schimmel
In-Reply-To: <20190128120131.2848-1-idosch@mellanox.com>
From: Jiri Pirko <jiri@mellanox.com>
No need to pass ruleset/group and chunk pointers on action_replace call
path, nobody uses them.
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum.h | 3 +--
.../net/ethernet/mellanox/mlxsw/spectrum1_acl_tcam.c | 3 +--
.../net/ethernet/mellanox/mlxsw/spectrum2_acl_tcam.c | 5 +----
drivers/net/ethernet/mellanox/mlxsw/spectrum_acl.c | 3 +--
.../net/ethernet/mellanox/mlxsw/spectrum_acl_atcam.c | 2 --
.../net/ethernet/mellanox/mlxsw/spectrum_acl_ctcam.c | 1 -
.../net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c | 11 ++++-------
.../net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.h | 5 +----
8 files changed, 9 insertions(+), 24 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.h b/drivers/net/ethernet/mellanox/mlxsw/spectrum.h
index 9384b108c8c2..4fe0996c7cdd 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.h
@@ -721,8 +721,7 @@ struct mlxsw_sp_acl_tcam_ops {
void *region_priv, void *chunk_priv,
void *entry_priv);
int (*entry_action_replace)(struct mlxsw_sp *mlxsw_sp,
- void *region_priv, void *chunk_priv,
- void *entry_priv,
+ void *region_priv, void *entry_priv,
struct mlxsw_sp_acl_rule_info *rulei);
int (*entry_activity_get)(struct mlxsw_sp *mlxsw_sp,
void *region_priv, void *entry_priv,
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum1_acl_tcam.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum1_acl_tcam.c
index fe270c1a26a6..6e444525713f 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum1_acl_tcam.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum1_acl_tcam.c
@@ -194,8 +194,7 @@ static void mlxsw_sp1_acl_tcam_entry_del(struct mlxsw_sp *mlxsw_sp,
static int
mlxsw_sp1_acl_tcam_entry_action_replace(struct mlxsw_sp *mlxsw_sp,
- void *region_priv, void *chunk_priv,
- void *entry_priv,
+ void *region_priv, void *entry_priv,
struct mlxsw_sp_acl_rule_info *rulei)
{
return -EOPNOTSUPP;
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum2_acl_tcam.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum2_acl_tcam.c
index 234ab51916db..d380b3403960 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum2_acl_tcam.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum2_acl_tcam.c
@@ -212,18 +212,15 @@ static void mlxsw_sp2_acl_tcam_entry_del(struct mlxsw_sp *mlxsw_sp,
static int
mlxsw_sp2_acl_tcam_entry_action_replace(struct mlxsw_sp *mlxsw_sp,
- void *region_priv, void *chunk_priv,
- void *entry_priv,
+ void *region_priv, void *entry_priv,
struct mlxsw_sp_acl_rule_info *rulei)
{
struct mlxsw_sp2_acl_tcam_region *region = region_priv;
- struct mlxsw_sp2_acl_tcam_chunk *chunk = chunk_priv;
struct mlxsw_sp2_acl_tcam_entry *entry = entry_priv;
entry->act_block = rulei->act_block;
return mlxsw_sp_acl_atcam_entry_action_replace(mlxsw_sp,
®ion->aregion,
- &chunk->achunk,
&entry->aentry, rulei);
}
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl.c
index 695d33358988..bd40ed065f3e 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl.c
@@ -742,8 +742,7 @@ int mlxsw_sp_acl_rule_action_replace(struct mlxsw_sp *mlxsw_sp,
rulei = mlxsw_sp_acl_rule_rulei(rule);
rulei->act_block = afa_block;
- return ops->rule_action_replace(mlxsw_sp, ruleset->priv, rule->priv,
- rule->rulei);
+ return ops->rule_action_replace(mlxsw_sp, rule->priv, rule->rulei);
}
struct mlxsw_sp_acl_rule *
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_atcam.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_atcam.c
index 80fb268d51a5..40dc76a5c412 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_atcam.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_atcam.c
@@ -603,7 +603,6 @@ void mlxsw_sp_acl_atcam_entry_del(struct mlxsw_sp *mlxsw_sp,
int
mlxsw_sp_acl_atcam_entry_action_replace(struct mlxsw_sp *mlxsw_sp,
struct mlxsw_sp_acl_atcam_region *aregion,
- struct mlxsw_sp_acl_atcam_chunk *achunk,
struct mlxsw_sp_acl_atcam_entry *aentry,
struct mlxsw_sp_acl_rule_info *rulei)
{
@@ -612,7 +611,6 @@ mlxsw_sp_acl_atcam_entry_action_replace(struct mlxsw_sp *mlxsw_sp,
if (mlxsw_sp_acl_atcam_is_centry(aentry))
err = mlxsw_sp_acl_ctcam_entry_action_replace(mlxsw_sp,
&aregion->cregion,
- &achunk->cchunk,
&aentry->centry,
rulei);
else
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_ctcam.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_ctcam.c
index ac222833a5cf..05680a7e6c56 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_ctcam.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_ctcam.c
@@ -223,7 +223,6 @@ void mlxsw_sp_acl_ctcam_entry_del(struct mlxsw_sp *mlxsw_sp,
int mlxsw_sp_acl_ctcam_entry_action_replace(struct mlxsw_sp *mlxsw_sp,
struct mlxsw_sp_acl_ctcam_region *cregion,
- struct mlxsw_sp_acl_ctcam_chunk *cchunk,
struct mlxsw_sp_acl_ctcam_entry *centry,
struct mlxsw_sp_acl_rule_info *rulei)
{
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c
index fe230acf92a9..5d29c5050401 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c
@@ -781,7 +781,6 @@ static void mlxsw_sp_acl_tcam_entry_del(struct mlxsw_sp *mlxsw_sp,
static int
mlxsw_sp_acl_tcam_entry_action_replace(struct mlxsw_sp *mlxsw_sp,
- struct mlxsw_sp_acl_tcam_group *group,
struct mlxsw_sp_acl_tcam_entry *entry,
struct mlxsw_sp_acl_rule_info *rulei)
{
@@ -789,7 +788,7 @@ mlxsw_sp_acl_tcam_entry_action_replace(struct mlxsw_sp *mlxsw_sp,
struct mlxsw_sp_acl_tcam_chunk *chunk = entry->chunk;
struct mlxsw_sp_acl_tcam_region *region = chunk->region;
- return ops->entry_action_replace(mlxsw_sp, region->priv, chunk->priv,
+ return ops->entry_action_replace(mlxsw_sp, region->priv,
entry->priv, rulei);
}
@@ -955,7 +954,6 @@ mlxsw_sp_acl_tcam_flower_rule_del(struct mlxsw_sp *mlxsw_sp, void *rule_priv)
static int
mlxsw_sp_acl_tcam_flower_rule_action_replace(struct mlxsw_sp *mlxsw_sp,
- void *ruleset_priv,
void *rule_priv,
struct mlxsw_sp_acl_rule_info *rulei)
{
@@ -1084,14 +1082,13 @@ mlxsw_sp_acl_tcam_mr_rule_del(struct mlxsw_sp *mlxsw_sp, void *rule_priv)
static int
mlxsw_sp_acl_tcam_mr_rule_action_replace(struct mlxsw_sp *mlxsw_sp,
- void *ruleset_priv, void *rule_priv,
+ void *rule_priv,
struct mlxsw_sp_acl_rule_info *rulei)
{
- struct mlxsw_sp_acl_tcam_mr_ruleset *ruleset = ruleset_priv;
struct mlxsw_sp_acl_tcam_mr_rule *rule = rule_priv;
- return mlxsw_sp_acl_tcam_entry_action_replace(mlxsw_sp, &ruleset->group,
- &rule->entry, rulei);
+ return mlxsw_sp_acl_tcam_entry_action_replace(mlxsw_sp, &rule->entry,
+ rulei);
}
static int
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.h b/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.h
index 0f1a9dee63de..10512b7c6d50 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.h
@@ -48,8 +48,7 @@ struct mlxsw_sp_acl_profile_ops {
void *ruleset_priv, void *rule_priv,
struct mlxsw_sp_acl_rule_info *rulei);
void (*rule_del)(struct mlxsw_sp *mlxsw_sp, void *rule_priv);
- int (*rule_action_replace)(struct mlxsw_sp *mlxsw_sp,
- void *ruleset_priv, void *rule_priv,
+ int (*rule_action_replace)(struct mlxsw_sp *mlxsw_sp, void *rule_priv,
struct mlxsw_sp_acl_rule_info *rulei);
int (*rule_activity_get)(struct mlxsw_sp *mlxsw_sp, void *rule_priv,
bool *activity);
@@ -126,7 +125,6 @@ void mlxsw_sp_acl_ctcam_entry_del(struct mlxsw_sp *mlxsw_sp,
struct mlxsw_sp_acl_ctcam_entry *centry);
int mlxsw_sp_acl_ctcam_entry_action_replace(struct mlxsw_sp *mlxsw_sp,
struct mlxsw_sp_acl_ctcam_region *cregion,
- struct mlxsw_sp_acl_ctcam_chunk *cchunk,
struct mlxsw_sp_acl_ctcam_entry *centry,
struct mlxsw_sp_acl_rule_info *rulei);
static inline unsigned int
@@ -224,7 +222,6 @@ void mlxsw_sp_acl_atcam_entry_del(struct mlxsw_sp *mlxsw_sp,
struct mlxsw_sp_acl_atcam_entry *aentry);
int mlxsw_sp_acl_atcam_entry_action_replace(struct mlxsw_sp *mlxsw_sp,
struct mlxsw_sp_acl_atcam_region *aregion,
- struct mlxsw_sp_acl_atcam_chunk *achunk,
struct mlxsw_sp_acl_atcam_entry *aentry,
struct mlxsw_sp_acl_rule_info *rulei);
int mlxsw_sp_acl_atcam_init(struct mlxsw_sp *mlxsw_sp,
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 2/7] mlxsw: spectrum_acl: Move mr_ruleset and mr_rule structs
From: Ido Schimmel @ 2019-01-28 12:02 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: davem@davemloft.net, Jiri Pirko, mlxsw, Ido Schimmel
In-Reply-To: <20190128120131.2848-1-idosch@mellanox.com>
From: Jiri Pirko <jiri@mellanox.com>
Move the struct to the place where they belong, alongside with the rest
of the MR code.
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
.../mellanox/mlxsw/spectrum_acl_tcam.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c
index 5d29c5050401..11456e1f236f 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl_tcam.c
@@ -862,15 +862,6 @@ struct mlxsw_sp_acl_tcam_flower_rule {
struct mlxsw_sp_acl_tcam_entry entry;
};
-struct mlxsw_sp_acl_tcam_mr_ruleset {
- struct mlxsw_sp_acl_tcam_chunk *chunk;
- struct mlxsw_sp_acl_tcam_group group;
-};
-
-struct mlxsw_sp_acl_tcam_mr_rule {
- struct mlxsw_sp_acl_tcam_entry entry;
-};
-
static int
mlxsw_sp_acl_tcam_flower_ruleset_add(struct mlxsw_sp *mlxsw_sp,
struct mlxsw_sp_acl_tcam *tcam,
@@ -984,6 +975,15 @@ static const struct mlxsw_sp_acl_profile_ops mlxsw_sp_acl_tcam_flower_ops = {
.rule_activity_get = mlxsw_sp_acl_tcam_flower_rule_activity_get,
};
+struct mlxsw_sp_acl_tcam_mr_ruleset {
+ struct mlxsw_sp_acl_tcam_chunk *chunk;
+ struct mlxsw_sp_acl_tcam_group group;
+};
+
+struct mlxsw_sp_acl_tcam_mr_rule {
+ struct mlxsw_sp_acl_tcam_entry entry;
+};
+
static int
mlxsw_sp_acl_tcam_mr_ruleset_add(struct mlxsw_sp *mlxsw_sp,
struct mlxsw_sp_acl_tcam *tcam,
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 7/7] selftests: forwarding: Use OK instead of PASS in test output
From: Ido Schimmel @ 2019-01-28 12:02 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: davem@davemloft.net, Jiri Pirko, mlxsw, Ido Schimmel, David Ahern
In-Reply-To: <20190128120131.2848-1-idosch@mellanox.com>
It is easier to distinguish "[ OK ]" from "[FAIL]" than "[PASS]".
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Suggested-by: David Ahern <dsahern@gmail.com>
Cc: David Ahern <dsahern@gmail.com>
---
tools/testing/selftests/net/forwarding/lib.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/net/forwarding/lib.sh b/tools/testing/selftests/net/forwarding/lib.sh
index 3f248d1f5b91..c1f16bb992dc 100644
--- a/tools/testing/selftests/net/forwarding/lib.sh
+++ b/tools/testing/selftests/net/forwarding/lib.sh
@@ -211,7 +211,7 @@ log_test()
return 1
fi
- printf "TEST: %-60s [PASS]\n" "$test_name $opt_str"
+ printf "TEST: %-60s [ OK ]\n" "$test_name $opt_str"
return 0
}
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 3/7] mlxsw: spectrum_acl: Fix rul/rule typo
From: Ido Schimmel @ 2019-01-28 12:02 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: davem@davemloft.net, Jiri Pirko, mlxsw, Ido Schimmel
In-Reply-To: <20190128120131.2848-1-idosch@mellanox.com>
From: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum_acl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl.c
index bd40ed065f3e..a69e3462b65e 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_acl.c
@@ -805,7 +805,7 @@ static void mlxsw_sp_acl_rule_activity_work_schedule(struct mlxsw_sp_acl *acl)
msecs_to_jiffies(interval));
}
-static void mlxsw_sp_acl_rul_activity_update_work(struct work_struct *work)
+static void mlxsw_sp_acl_rule_activity_update_work(struct work_struct *work)
{
struct mlxsw_sp_acl *acl = container_of(work, struct mlxsw_sp_acl,
rule_activity_update.dw.work);
@@ -884,7 +884,7 @@ int mlxsw_sp_acl_init(struct mlxsw_sp *mlxsw_sp)
/* Create the delayed work for the rule activity_update */
INIT_DELAYED_WORK(&acl->rule_activity_update.dw,
- mlxsw_sp_acl_rul_activity_update_work);
+ mlxsw_sp_acl_rule_activity_update_work);
acl->rule_activity_update.interval = MLXSW_SP_ACL_RULE_ACTIVITY_UPDATE_PERIOD_MS;
mlxsw_core_schedule_dw(&acl->rule_activity_update.dw, 0);
return 0;
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 4/7] mlxsw: spectrum_switchdev: Add more extack messages
From: Ido Schimmel @ 2019-01-28 12:02 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: davem@davemloft.net, Jiri Pirko, mlxsw, Ido Schimmel, David Ahern
In-Reply-To: <20190128120131.2848-1-idosch@mellanox.com>
Add more extack messages that let the user know why VXLAN offload
failed.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Suggested-by: David Ahern <dsahern@gmail.com>
Cc: David Ahern <dsahern@gmail.com>
---
.../net/ethernet/mellanox/mlxsw/spectrum_switchdev.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
index 0f4e68d31cc3..a4a9fe992193 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c
@@ -2027,6 +2027,7 @@ mlxsw_sp_bridge_8021q_vxlan_join(struct mlxsw_sp_bridge_device *bridge_device,
return 0;
if (mlxsw_sp_fid_vni_is_set(fid)) {
+ NL_SET_ERR_MSG_MOD(extack, "VNI is already set on FID");
err = -EINVAL;
goto err_vni_exists;
}
@@ -2213,10 +2214,13 @@ mlxsw_sp_bridge_8021d_vxlan_join(struct mlxsw_sp_bridge_device *bridge_device,
int err;
fid = mlxsw_sp_fid_8021d_lookup(mlxsw_sp, bridge_device->dev->ifindex);
- if (!fid)
+ if (!fid) {
+ NL_SET_ERR_MSG_MOD(extack, "Did not find a corresponding FID");
return -EINVAL;
+ }
if (mlxsw_sp_fid_vni_is_set(fid)) {
+ NL_SET_ERR_MSG_MOD(extack, "VNI is already set on FID");
err = -EINVAL;
goto err_vni_exists;
}
@@ -3231,8 +3235,10 @@ mlxsw_sp_switchdev_vxlan_vlan_add(struct mlxsw_sp *mlxsw_sp,
* the lookup function to return 'vxlan_dev'
*/
if (flag_untagged && flag_pvid &&
- mlxsw_sp_bridge_8021q_vxlan_dev_find(bridge_device->dev, vid))
+ mlxsw_sp_bridge_8021q_vxlan_dev_find(bridge_device->dev, vid)) {
+ NL_SET_ERR_MSG_MOD(extack, "VLAN already mapped to a different VNI");
return -EINVAL;
+ }
if (!netif_running(vxlan_dev))
return 0;
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 5/7] Documentation: add devlink param file for mlxsw driver
From: Ido Schimmel @ 2019-01-28 12:02 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: davem@davemloft.net, Jiri Pirko, mlxsw, Ido Schimmel
In-Reply-To: <20190128120131.2848-1-idosch@mellanox.com>
From: Jiri Pirko <jiri@mellanox.com>
Add initial documentation file for devlink params of mlxsw driver. Only
"fw_load_policy" is now supported.
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
Documentation/networking/devlink-params-mlxsw.txt | 2 ++
1 file changed, 2 insertions(+)
create mode 100644 Documentation/networking/devlink-params-mlxsw.txt
diff --git a/Documentation/networking/devlink-params-mlxsw.txt b/Documentation/networking/devlink-params-mlxsw.txt
new file mode 100644
index 000000000000..2c5c67a920c9
--- /dev/null
+++ b/Documentation/networking/devlink-params-mlxsw.txt
@@ -0,0 +1,2 @@
+fw_load_policy [DEVICE, GENERIC]
+ Configuration mode: driverinit
--
2.20.1
^ permalink raw reply related
* [PATCH net-next 6/7] selftests: net: forwarding: change devlink resource support checking
From: Ido Schimmel @ 2019-01-28 12:02 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: davem@davemloft.net, Jiri Pirko, mlxsw, Ido Schimmel
In-Reply-To: <20190128120131.2848-1-idosch@mellanox.com>
From: Jiri Pirko <jiri@mellanox.com>
As for the others, check help message output to find out if devlink
supports "resource" object.
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
---
tools/testing/selftests/net/forwarding/devlink_lib.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/net/forwarding/devlink_lib.sh b/tools/testing/selftests/net/forwarding/devlink_lib.sh
index 5ab1e5f43022..57cf8914910d 100644
--- a/tools/testing/selftests/net/forwarding/devlink_lib.sh
+++ b/tools/testing/selftests/net/forwarding/devlink_lib.sh
@@ -32,7 +32,7 @@ DEVLINK_VIDDID=$(lspci -s $(echo $DEVLINK_DEV | cut -d"/" -f2) \
##############################################################################
# Sanity checks
-devlink -j resource show "$DEVLINK_DEV" &> /dev/null
+devlink help 2>&1 | grep resource &> /dev/null
if [ $? -ne 0 ]; then
echo "SKIP: iproute2 too old, missing devlink resource support"
exit 1
--
2.20.1
^ permalink raw reply related
* Re: [PATCH net v4 2/2] net/mlx5e: Don't overwrite pedit action when multiple pedit used
From: Tonghao Zhang @ 2019-01-28 12:09 UTC (permalink / raw)
To: Or Gerlitz; +Cc: Saeed Mahameed, Linux Netdev List, Or Gerlitz
In-Reply-To: <CAJ3xEMjrLgJspjY-Aqd68GzWMrFuHHiAOjoazi9p1T8BhuPP=w@mail.gmail.com>
On Mon, Jan 28, 2019 at 12:40 AM Or Gerlitz <gerlitz.or@gmail.com> wrote:
>
> On Sun, Jan 27, 2019 at 1:06 PM <xiangxia.m.yue@gmail.com> wrote:
> > From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
> >
> > In some case, we may use multiple pedit actions to modify packets.
> > The command shown as below: the last pedit action is effective.
>
> > @@ -2073,7 +2076,8 @@ static int alloc_mod_hdr_actions(struct mlx5e_priv *priv,
> > if (!parse_attr->mod_hdr_actions)
> > return -ENOMEM;
> >
> > - parse_attr->num_mod_hdr_actions = max_actions;
> > + parse_attr->max_mod_hdr_actions = max_actions;
> > + parse_attr->num_mod_hdr_actions = 0;
>
> why would we want to do this zeroing? what purpose does it serve?
Because we use the num_mod_hdr_actions to store the number of actions
we have parsed,
and when we alloc it, we init it 0 as default.
> On a probably related note, I suspect that the patch broke the caching
> we do for modify header contexts, see mlx5e_attach_mod_hdr where we
> look if a given set of modify header operations already has hw modify header
> context and we use it.
>
> To test that, put two tc rules with different matching but same set of
> modify header
> (pedit) actions and see that only one modify header context is used.
The patch does't break the cache, I think that different matching may
share the same set of
pedit actions.
I use the tc filters to test it: only one same pedit actions in hw,
and after deleting one tc filter, other filter work fine.
tc filter add dev eth4_0 parent ffff: protocol ip prio 1 \
flower skip_sw ip_proto icmp dst_ip 3.3.3.3 \
action pedit ex munge ip dst set 192.168.1.100 pipe \
action pedit ex munge eth src set 00:00:00:00:00:01 pipe \
action pedit ex munge eth dst set 00:00:00:00:00:02 pipe \
action csum ip pipe \
action tunnel_key set src_ip 192.168.6.2 dst_ip 192.168.10.2
dst_port 4789 id 100 \
action mirred egress redirect dev vxlan0
note: match 3.3.3.3, vxlan id 100
tc filter add dev eth4_0 parent ffff: protocol ip prio 1 \
flower skip_sw ip_proto icmp dst_ip 3.3.3.4 \
action pedit ex munge ip dst set 192.168.1.100 pipe \
action pedit ex munge eth src set 00:00:00:00:00:01 pipe \
action pedit ex munge eth dst set 00:00:00:00:00:02 pipe \
action csum ip pipe \
action tunnel_key set src_ip 192.168.6.2 dst_ip 192.168.10.2
dst_port 4789 id 200 \
action mirred egress redirect dev vxlan0
note: match 3.3.3.4, vxlan id 200
^ permalink raw reply
* Re: [PATCH 2/7] sh_eth: RX checksum offload support
From: Simon Horman @ 2019-01-28 12:18 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: netdev, David S. Miller, linux-renesas-soc, linux-sh
In-Reply-To: <29cb4d33-37c3-43c0-3bce-fa01737c0fa4@cogentembedded.com>
Hi Sergei,
On Sun, Jan 27, 2019 at 08:37:33PM +0300, Sergei Shtylyov wrote:
> Add support for the RX checksum offload. This is enabled by default and
> may be disabled and re-enabled using 'ethtool':
>
> # ethtool -K eth0 rx {on|off}
>
> Some Ether MACs provide a simple checksumming scheme which appears to be
> completely compatible with CHECKSUM_COMPLETE: sum of all packet data after
> the L2 header is appended to packet data; this may be trivially read by
> the driver and used to update the skb accordingly. The same checksumming
> scheme is implemented in the EtherAVB MACs and now supported by tha 'ravb'
> driver.
>
> In terms of performance, throughput is close to gigabit line rate with the
> RX checksum offload both enabled and disabled. The 'perf' output, however,
> appears to indicate that significantly less time is spent in do_csum() --
> this is as expected.
Nice.
FYI, this seems similar to what I observed for RAVB, perhaps on H3 I don't
exactly recall. On E3, which has less CPU power, I recently observed that
with rx-csum enabled I can achieve gigabit line rate, but with rx-csum
disabled throughput is significantly lower. I.e. on that system throughput
is CPU bound with 1500 byte packets unless rx-csum enabled.
Next point:
2da64300fbc ("ravb: expand rx descriptor data to accommodate hw checksum")
is fresh in my mind and I wonder if mdp->rx_buf_sz needs to grow to ensure
that there is always enough space for the csum. In particular, have you
tested this with MTU-size frames with VLANs. (My test is to run iperf3 over
a VLAN netdev, netperf over a VLAN netdev would likely work just as well.)
>
> Test results with RX checksum offload enabled:
>
> ~/netperf-2.2pl4# perf record -a ./netperf -t TCP_MAERTS -H 192.168.2.4
> TCP MAERTS TEST to 192.168.2.4
> Recv Send Send
> Socket Socket Message Elapsed
> Size Size Size Time Throughput
> bytes bytes bytes secs. 10^6bits/sec
>
> 131072 16384 16384 10.01 933.93
> [ perf record: Woken up 8 times to write data ]
> [ perf record: Captured and wrote 1.955 MB perf.data (41940 samples) ]
> ~/netperf-2.2pl4# perf report
> Samples: 41K of event 'cycles:ppp', Event count (approx.): 9915302763
> Overhead Command Shared Object Symbol
> 9.44% netperf [kernel.kallsyms] [k] __arch_copy_to_user
> 7.75% swapper [kernel.kallsyms] [k] _raw_spin_unlock_irq
> 6.31% swapper [kernel.kallsyms] [k] default_idle_call
> 5.89% swapper [kernel.kallsyms] [k] arch_cpu_idle
> 4.37% swapper [kernel.kallsyms] [k] tick_nohz_idle_exit
> 4.02% netperf [kernel.kallsyms] [k] _raw_spin_unlock_irq
> 2.52% netperf [kernel.kallsyms] [k] preempt_count_sub
> 1.81% netperf [kernel.kallsyms] [k] tcp_recvmsg
> 1.80% netperf [kernel.kallsyms] [k] _raw_spin_unlock_irqres
> 1.78% netperf [kernel.kallsyms] [k] preempt_count_add
> 1.36% netperf [kernel.kallsyms] [k] __tcp_transmit_skb
> 1.20% netperf [kernel.kallsyms] [k] __local_bh_enable_ip
> 1.10% netperf [kernel.kallsyms] [k] sh_eth_start_xmit
>
> Test results with RX checksum offload disabled:
>
> ~/netperf-2.2pl4# perf record -a ./netperf -t TCP_MAERTS -H 192.168.2.4
> TCP MAERTS TEST to 192.168.2.4
> Recv Send Send
> Socket Socket Message Elapsed
> Size Size Size Time Throughput
> bytes bytes bytes secs. 10^6bits/sec
> 131072 16384 16384 10.01 932.04
> [ perf record: Woken up 14 times to write data ]
> [ perf record: Captured and wrote 3.642 MB perf.data (78817 samples) ]
> ~/netperf-2.2pl4# perf report
> Samples: 78K of event 'cycles:ppp', Event count (approx.): 18091442796
> Overhead Command Shared Object Symbol
> 7.00% swapper [kernel.kallsyms] [k] do_csum
> 3.94% swapper [kernel.kallsyms] [k] sh_eth_poll
> 3.83% ksoftirqd/0 [kernel.kallsyms] [k] do_csum
> 3.23% swapper [kernel.kallsyms] [k] _raw_spin_unlock_irq
> 2.87% netperf [kernel.kallsyms] [k] __arch_copy_to_user
> 2.86% swapper [kernel.kallsyms] [k] arch_cpu_idle
> 2.13% swapper [kernel.kallsyms] [k] default_idle_call
> 2.12% ksoftirqd/0 [kernel.kallsyms] [k] sh_eth_poll
> 2.02% swapper [kernel.kallsyms] [k] _raw_spin_unlock_irqrestore
> 1.84% swapper [kernel.kallsyms] [k] __softirqentry_text_start
> 1.64% swapper [kernel.kallsyms] [k] tick_nohz_idle_exit
> 1.53% netperf [kernel.kallsyms] [k] _raw_spin_unlock_irq
> 1.32% netperf [kernel.kallsyms] [k] preempt_count_sub
> 1.27% swapper [kernel.kallsyms] [k] __pi___inval_dcache_area
> 1.22% swapper [kernel.kallsyms] [k] check_preemption_disabled
> 1.01% ksoftirqd/0 [kernel.kallsyms] [k] _raw_spin_unlock_irqrestore
>
> The above results collected on the R-Car V3H Starter Kit board.
>
> Based on the commit 4d86d3818627 ("ravb: RX checksum offload")...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> ---
> drivers/net/ethernet/renesas/sh_eth.c | 60 ++++++++++++++++++++++++++++++++--
> drivers/net/ethernet/renesas/sh_eth.h | 1
> 2 files changed, 59 insertions(+), 2 deletions(-)
>
> Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
> ===================================================================
> --- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
> +++ net-next/drivers/net/ethernet/renesas/sh_eth.c
> @@ -1532,8 +1532,9 @@ static int sh_eth_dev_init(struct net_de
> mdp->irq_enabled = true;
> sh_eth_write(ndev, mdp->cd->eesipr_value, EESIPR);
>
> - /* PAUSE Prohibition */
> + /* EMAC Mode: PAUSE prohibition; Duplex; RX Checksum; TX; RX */
> sh_eth_write(ndev, ECMR_ZPF | (mdp->duplex ? ECMR_DM : 0) |
> + (ndev->features & NETIF_F_RXCSUM ? ECMR_RCSC : 0) |
> ECMR_TE | ECMR_RE, ECMR);
>
> if (mdp->cd->set_rate)
> @@ -1592,6 +1593,19 @@ static void sh_eth_dev_exit(struct net_d
> update_mac_address(ndev);
> }
>
> +static void sh_eth_rx_csum(struct sk_buff *skb)
> +{
> + u8 *hw_csum;
> +
> + /* The hardware checksum is 2 bytes appended to packet data */
> + if (unlikely(skb->len < sizeof(__sum16)))
> + return;
> + hw_csum = skb_tail_pointer(skb) - sizeof(__sum16);
> + skb->csum = csum_unfold((__force __sum16)get_unaligned_le16(hw_csum));
> + skb->ip_summed = CHECKSUM_COMPLETE;
> + skb_trim(skb, skb->len - sizeof(__sum16));
> +}
> +
> /* Packet receive function */
> static int sh_eth_rx(struct net_device *ndev, u32 intr_status, int *quota)
> {
> @@ -1666,6 +1680,8 @@ static int sh_eth_rx(struct net_device *
> DMA_FROM_DEVICE);
> skb_put(skb, pkt_len);
> skb->protocol = eth_type_trans(skb, ndev);
> + if (ndev->features & NETIF_F_RXCSUM)
> + sh_eth_rx_csum(skb);
> netif_receive_skb(skb);
> ndev->stats.rx_packets++;
> ndev->stats.rx_bytes += pkt_len;
> @@ -2921,6 +2937,39 @@ static void sh_eth_set_rx_mode(struct ne
> spin_unlock_irqrestore(&mdp->lock, flags);
> }
>
> +static void sh_eth_set_rx_csum(struct net_device *ndev, bool enable)
> +{
> + struct sh_eth_private *mdp = netdev_priv(ndev);
> + unsigned long flags;
> +
> + spin_lock_irqsave(&mdp->lock, flags);
> +
> + /* Disable TX and RX */
> + sh_eth_rcv_snd_disable(ndev);
> +
> + /* Modify RX Checksum setting */
> + sh_eth_modify(ndev, ECMR, ECMR_RCSC, enable ? ECMR_RCSC : 0);
> +
> + /* Enable TX and RX */
> + sh_eth_rcv_snd_enable(ndev);
> +
> + spin_unlock_irqrestore(&mdp->lock, flags);
> +}
> +
> +static int sh_eth_set_features(struct net_device *ndev,
> + netdev_features_t features)
> +{
> + netdev_features_t changed = ndev->features ^ features;
> + struct sh_eth_private *mdp = netdev_priv(ndev);
> +
> + if (changed & NETIF_F_RXCSUM && mdp->cd->rx_csum)
> + sh_eth_set_rx_csum(ndev, features & NETIF_F_RXCSUM);
> +
> + ndev->features = features;
> +
> + return 0;
> +}
> +
> static int sh_eth_get_vtag_index(struct sh_eth_private *mdp)
> {
> if (!mdp->port)
> @@ -3102,6 +3151,7 @@ static const struct net_device_ops sh_et
> .ndo_change_mtu = sh_eth_change_mtu,
> .ndo_validate_addr = eth_validate_addr,
> .ndo_set_mac_address = eth_mac_addr,
> + .ndo_set_features = sh_eth_set_features,
> };
>
> static const struct net_device_ops sh_eth_netdev_ops_tsu = {
> @@ -3117,6 +3167,7 @@ static const struct net_device_ops sh_et
> .ndo_change_mtu = sh_eth_change_mtu,
> .ndo_validate_addr = eth_validate_addr,
> .ndo_set_mac_address = eth_mac_addr,
> + .ndo_set_features = sh_eth_set_features,
> };
>
> #ifdef CONFIG_OF
> @@ -3245,6 +3296,11 @@ static int sh_eth_drv_probe(struct platf
> ndev->max_mtu = 2000 - (ETH_HLEN + VLAN_HLEN + ETH_FCS_LEN);
> ndev->min_mtu = ETH_MIN_MTU;
>
> + if (mdp->cd->rx_csum) {
> + ndev->features = NETIF_F_RXCSUM;
> + ndev->hw_features = NETIF_F_RXCSUM;
> + }
> +
> /* set function */
> if (mdp->cd->tsu)
> ndev->netdev_ops = &sh_eth_netdev_ops_tsu;
> @@ -3294,7 +3350,7 @@ static int sh_eth_drv_probe(struct platf
> goto out_release;
> }
> mdp->port = port;
> - ndev->features = NETIF_F_HW_VLAN_CTAG_FILTER;
> + ndev->features |= NETIF_F_HW_VLAN_CTAG_FILTER;
>
> /* Need to init only the first port of the two sharing a TSU */
> if (port == 0) {
> Index: net-next/drivers/net/ethernet/renesas/sh_eth.h
> ===================================================================
> --- net-next.orig/drivers/net/ethernet/renesas/sh_eth.h
> +++ net-next/drivers/net/ethernet/renesas/sh_eth.h
> @@ -500,6 +500,7 @@ struct sh_eth_cpu_data {
> unsigned no_xdfar:1; /* E-DMAC DOES NOT have RDFAR/TDFAR */
> unsigned xdfar_rw:1; /* E-DMAC has writeable RDFAR/TDFAR */
> unsigned csmr:1; /* E-DMAC has CSMR */
> + unsigned rx_csum:1; /* EtherC has ECMR.RCSC */
> unsigned select_mii:1; /* EtherC has RMII_MII (MII select register) */
> unsigned rmiimode:1; /* EtherC has RMIIMODE register */
> unsigned rtrate:1; /* EtherC has RTRATE register */
>
^ permalink raw reply
* Re: [PATCH 3/7] sh_eth: offload RX checksum on R7S72100
From: Simon Horman @ 2019-01-28 12:20 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: netdev, David S. Miller, linux-renesas-soc, linux-sh
In-Reply-To: <0476beba-ea1f-7675-aa08-573b74e84f4e@cogentembedded.com>
On Sun, Jan 27, 2019 at 08:38:33PM +0300, Sergei Shtylyov wrote:
> The RZ/A1H (R7S721000) SoC manual describes the Ether MAC's RX checksum
> offload the same way as it's implemented in the EtherAVB MACs...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Regarding this and the remaining patches in this series,
which add rx-csum offload support in the sh_eth driver for
various SoCs: has this been tested?
^ permalink raw reply
* [PATCH net-next v8 5/8] devlink: Add support for driverinit set value for devlink_port
From: Vasundhara Volam @ 2019-01-28 12:30 UTC (permalink / raw)
To: davem; +Cc: michael.chan, jiri, jakub.kicinski, mkubecek, netdev
In-Reply-To: <1548678627-21938-1-git-send-email-vasundhara-v.volam@broadcom.com>
Add support for "driverinit" configuration mode value for devlink_port
configuration parameters. Add devlink_port_param_driverinit_value_set()
function to help the driver set the value to devlink_port.
Also, move the common code to __devlink_param_driverinit_value_set()
to be used by both device and port params.
v7->v8:
Re-order the definitions as follows:
__devlink_param_driverinit_value_get
__devlink_param_driverinit_value_set
devlink_param_driverinit_value_get
devlink_param_driverinit_value_set
devlink_port_param_driverinit_value_get
devlink_port_param_driverinit_value_set
Cc: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
---
include/net/devlink.h | 11 ++++++++
net/core/devlink.c | 70 ++++++++++++++++++++++++++++++++++++++-------------
2 files changed, 63 insertions(+), 18 deletions(-)
diff --git a/include/net/devlink.h b/include/net/devlink.h
index 3943072..ae2ccf29 100644
--- a/include/net/devlink.h
+++ b/include/net/devlink.h
@@ -582,6 +582,9 @@ int devlink_param_driverinit_value_set(struct devlink *devlink, u32 param_id,
devlink_port_param_driverinit_value_get(struct devlink_port *devlink_port,
u32 param_id,
union devlink_param_value *init_val);
+int devlink_port_param_driverinit_value_set(struct devlink_port *devlink_port,
+ u32 param_id,
+ union devlink_param_value init_val);
void devlink_param_value_changed(struct devlink *devlink, u32 param_id);
void devlink_param_value_str_fill(union devlink_param_value *dst_val,
const char *src);
@@ -839,6 +842,14 @@ static inline bool devlink_dpipe_table_counter_enabled(struct devlink *devlink,
return -EOPNOTSUPP;
}
+static inline int
+devlink_port_param_driverinit_value_set(struct devlink_port *devlink_port,
+ u32 param_id,
+ union devlink_param_value init_val)
+{
+ return -EOPNOTSUPP;
+}
+
static inline void
devlink_param_value_changed(struct devlink *devlink, u32 param_id)
{
diff --git a/net/core/devlink.c b/net/core/devlink.c
index fdfdb9b..55456cc 100644
--- a/net/core/devlink.c
+++ b/net/core/devlink.c
@@ -4737,6 +4737,32 @@ void devlink_port_params_unregister(struct devlink_port *devlink_port,
return 0;
}
+static int
+__devlink_param_driverinit_value_set(struct devlink *devlink,
+ struct list_head *param_list, u32 param_id,
+ union devlink_param_value init_val,
+ enum devlink_command cmd)
+{
+ struct devlink_param_item *param_item;
+
+ param_item = devlink_param_find_by_id(param_list, param_id);
+ if (!param_item)
+ return -EINVAL;
+
+ if (!devlink_param_cmode_is_supported(param_item->param,
+ DEVLINK_PARAM_CMODE_DRIVERINIT))
+ return -EOPNOTSUPP;
+
+ if (param_item->param->type == DEVLINK_PARAM_TYPE_STRING)
+ strcpy(param_item->driverinit_value.vstr, init_val.vstr);
+ else
+ param_item->driverinit_value = init_val;
+ param_item->driverinit_value_valid = true;
+
+ devlink_param_notify(devlink, param_item, DEVLINK_CMD_PARAM_NEW);
+ return 0;
+}
+
/**
* devlink_param_driverinit_value_get - get configuration parameter
* value for driver initializing
@@ -4774,24 +4800,10 @@ int devlink_param_driverinit_value_get(struct devlink *devlink, u32 param_id,
int devlink_param_driverinit_value_set(struct devlink *devlink, u32 param_id,
union devlink_param_value init_val)
{
- struct devlink_param_item *param_item;
-
- param_item = devlink_param_find_by_id(&devlink->param_list, param_id);
- if (!param_item)
- return -EINVAL;
-
- if (!devlink_param_cmode_is_supported(param_item->param,
- DEVLINK_PARAM_CMODE_DRIVERINIT))
- return -EOPNOTSUPP;
-
- if (param_item->param->type == DEVLINK_PARAM_TYPE_STRING)
- strcpy(param_item->driverinit_value.vstr, init_val.vstr);
- else
- param_item->driverinit_value = init_val;
- param_item->driverinit_value_valid = true;
-
- devlink_param_notify(devlink, param_item, DEVLINK_CMD_PARAM_NEW);
- return 0;
+ return __devlink_param_driverinit_value_set(devlink,
+ &devlink->param_list,
+ param_id, init_val,
+ DEVLINK_CMD_PARAM_NEW);
}
EXPORT_SYMBOL_GPL(devlink_param_driverinit_value_set);
@@ -4821,6 +4833,28 @@ int devlink_port_param_driverinit_value_get(struct devlink_port *devlink_port,
EXPORT_SYMBOL_GPL(devlink_port_param_driverinit_value_get);
/**
+ * devlink_port_param_driverinit_value_set - set value of configuration
+ * parameter for driverinit
+ * configuration mode
+ *
+ * @devlink_port: devlink_port
+ * @param_id: parameter ID
+ * @init_val: value of parameter to set for driverinit configuration mode
+ *
+ * This function should be used by the driver to set driverinit
+ * configuration mode default value.
+ */
+int devlink_port_param_driverinit_value_set(struct devlink_port *devlink_port,
+ u32 param_id,
+ union devlink_param_value init_val)
+{
+ return __devlink_param_driverinit_value_set(devlink_port->devlink,
+ &devlink_port->param_list,
+ param_id, init_val, 0);
+}
+EXPORT_SYMBOL_GPL(devlink_port_param_driverinit_value_set);
+
+/**
* devlink_param_value_changed - notify devlink on a parameter's value
* change. Should be called by the driver
* right after the change.
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next v8 8/8] bnxt_en: Add bnxt_en initial port params table and register it
From: Vasundhara Volam @ 2019-01-28 12:30 UTC (permalink / raw)
To: davem; +Cc: michael.chan, jiri, jakub.kicinski, mkubecek, netdev
In-Reply-To: <1548678627-21938-1-git-send-email-vasundhara-v.volam@broadcom.com>
Register devlink_port with devlink and create initial port params
table for bnxt_en. The table consists of a generic parameter:
wake_on_lan: Enables Wake on Lan for this port when magic packet
is received with this port's MAC address using ACPI pattern.
If enabled, the controller asserts a wake pin upon reception of
WoL packet. ACPI (Advanced Configuration and Power Interface) is
an industry specification for the efficient handling of power
consumption in desktop and mobile computers.
v2->v3:
- Modify bnxt_dl_wol_validate(), to throw error message when user gives
value other than DEVLINK_PARAM_WAKE_MAGIC ot to disable WOL.
- Use netdev_err() instead of netdev_warn(), when devlink_port_register()
and devlink_port_params_register() returns error. Also, don't log rc
in this message.
Cc: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.h | 1 +
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c | 43 ++++++++++++++++++++++-
drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h | 1 +
3 files changed, 44 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.h b/drivers/net/ethernet/broadcom/bnxt/bnxt.h
index a451796..5c886a7 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.h
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.h
@@ -1609,6 +1609,7 @@ struct bnxt {
/* devlink interface and vf-rep structs */
struct devlink *dl;
+ struct devlink_port dl_port;
enum devlink_eswitch_mode eswitch_mode;
struct bnxt_vf_rep **vf_reps; /* array of vf-rep ptrs */
u16 *cfa_code_map; /* cfa_code -> vf_idx map */
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
index 7f56032..a6abfa4 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.c
@@ -37,6 +37,8 @@ enum bnxt_dl_param_id {
NVM_OFF_MSIX_VEC_PER_PF_MIN, BNXT_NVM_SHARED_CFG, 7},
{BNXT_DEVLINK_PARAM_ID_GRE_VER_CHECK, NVM_OFF_DIS_GRE_VER_CHECK,
BNXT_NVM_SHARED_CFG, 1},
+
+ {DEVLINK_PARAM_GENERIC_ID_WOL, NVM_OFF_WOL, BNXT_NVM_PORT_CFG, 1},
};
static int bnxt_hwrm_nvm_req(struct bnxt *bp, u32 param_id, void *msg,
@@ -70,7 +72,8 @@ static int bnxt_hwrm_nvm_req(struct bnxt *bp, u32 param_id, void *msg,
bytesize = roundup(nvm_param.num_bits, BITS_PER_BYTE) / BITS_PER_BYTE;
switch (bytesize) {
case 1:
- if (nvm_param.num_bits == 1)
+ if (nvm_param.num_bits == 1 &&
+ nvm_param.id != DEVLINK_PARAM_GENERIC_ID_WOL)
buf = &val->vbool;
else
buf = &val->vu8;
@@ -164,6 +167,17 @@ static int bnxt_dl_msix_validate(struct devlink *dl, u32 id,
return 0;
}
+static int bnxt_dl_wol_validate(struct devlink *dl, u32 id,
+ union devlink_param_value val,
+ struct netlink_ext_ack *extack)
+{
+ if (val.vu8 && val.vu8 != DEVLINK_PARAM_WAKE_MAGIC) {
+ NL_SET_ERR_MSG_MOD(extack, "WOL type is not supported");
+ return -EINVAL;
+ }
+ return 0;
+}
+
static const struct devlink_param bnxt_dl_params[] = {
DEVLINK_PARAM_GENERIC(ENABLE_SRIOV,
BIT(DEVLINK_PARAM_CMODE_PERMANENT),
@@ -188,6 +202,12 @@ static int bnxt_dl_msix_validate(struct devlink *dl, u32 id,
NULL),
};
+static const struct devlink_param bnxt_dl_port_params[] = {
+ DEVLINK_PARAM_GENERIC(WOL, BIT(DEVLINK_PARAM_CMODE_PERMANENT),
+ bnxt_dl_nvm_param_get, bnxt_dl_nvm_param_set,
+ bnxt_dl_wol_validate),
+};
+
int bnxt_dl_register(struct bnxt *bp)
{
struct devlink *dl;
@@ -225,8 +245,26 @@ int bnxt_dl_register(struct bnxt *bp)
goto err_dl_unreg;
}
+ rc = devlink_port_register(dl, &bp->dl_port, bp->pf.port_id);
+ if (rc) {
+ netdev_err(bp->dev, "devlink_port_register failed");
+ goto err_dl_param_unreg;
+ }
+ devlink_port_type_eth_set(&bp->dl_port, bp->dev);
+
+ rc = devlink_port_params_register(&bp->dl_port, bnxt_dl_port_params,
+ ARRAY_SIZE(bnxt_dl_port_params));
+ if (rc) {
+ netdev_err(bp->dev, "devlink_port_params_register failed");
+ goto err_dl_port_unreg;
+ }
return 0;
+err_dl_port_unreg:
+ devlink_port_unregister(&bp->dl_port);
+err_dl_param_unreg:
+ devlink_params_unregister(dl, bnxt_dl_params,
+ ARRAY_SIZE(bnxt_dl_params));
err_dl_unreg:
devlink_unregister(dl);
err_dl_free:
@@ -242,6 +280,9 @@ void bnxt_dl_unregister(struct bnxt *bp)
if (!dl)
return;
+ devlink_port_params_unregister(&bp->dl_port, bnxt_dl_port_params,
+ ARRAY_SIZE(bnxt_dl_port_params));
+ devlink_port_unregister(&bp->dl_port);
devlink_params_unregister(dl, bnxt_dl_params,
ARRAY_SIZE(bnxt_dl_params));
devlink_unregister(dl);
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
index 5b6b2c7..da065ca 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_devlink.h
@@ -35,6 +35,7 @@ static inline void bnxt_link_bp_to_dl(struct bnxt *bp, struct devlink *dl)
#define NVM_OFF_MSIX_VEC_PER_PF_MAX 108
#define NVM_OFF_MSIX_VEC_PER_PF_MIN 114
+#define NVM_OFF_WOL 152
#define NVM_OFF_IGNORE_ARI 164
#define NVM_OFF_DIS_GRE_VER_CHECK 171
#define NVM_OFF_ENABLE_SRIOV 401
--
1.8.3.1
^ 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