* [pull request][net-next v2 00/16] Mellanox, mlx5 devlink RX health reporters
From: Saeed Mahameed @ 2019-08-20 20:24 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev@vger.kernel.org, Saeed Mahameed
Hi Dave,
This series is adding a new devlink health reporter for RX related
errors from Aya.
Last two patches from Vlad and Gavi, are trivial fixes for previously
submitted patches on this release cycle.
v1->v2:
- Improve reversed xmas tree variable declaration.
- Rebase on top of net-next to avoid a new conflict due to latest
merge with net.
For more information please see tag log below.
Please pull and let me know if there is any problem.
Thanks,
Saeed.
---
The following changes since commit d2187f8e445403b7aeb08e64c1528761154e9ab3:
r8152: divide the tx and rx bottom functions (2019-08-20 12:18:52 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux.git tags/mlx5-updates-2019-08-15
for you to fetch changes up to b1b9f97a0937211dbca638c476ac47ee39875661:
net/mlx5: Fix the order of fc_stats cleanup (2019-08-20 13:08:19 -0700)
----------------------------------------------------------------
mlx5-updates-2019-08-15
This patchset introduces changes in mlx5 devlink health reporters.
The highlight of these changes is adding a new reporter: RX reporter
mlx5 RX reporter: reports and recovers from timeouts and RX completion
error.
1) Perform TX reporter cleanup. In order to maintain the
code flow as similar as possible between RX and TX reporters, start the
set with cleanup.
2) Prepare for code sharing, generalize and move shared
functionality.
3) Refactor and extend TX reporter diagnostics information
to align the TX reporter diagnostics output with the RX reporter's
diagnostics output.
4) Add helper functions Patch 11: Add RX reporter, initially
supports only the diagnostics call back.
5) Change ICOSQ (Internal Operations Send Queue) open/close flow to
avoid race between interface down and completion error recovery.
6) Introduce recovery flows for RX ring population timeout on ICOSQ,
and for completion errors on ICOSQ and on RQ (Regular receive queues).
7) Include RX reporters in mlx5 documentation.
8) Last two patches of this series, are trivial fixes for previously
submitted patches on this release cycle.
----------------------------------------------------------------
Aya Levin (13):
net/mlx5e: Rename reporter header file
net/mlx5e: Change naming convention for reporter's functions
net/mlx5e: Generalize tx reporter's functionality
net/mlx5e: Extend tx diagnose function
net/mlx5e: Extend tx reporter diagnostics output
net/mlx5e: Add cq info to tx reporter diagnose
net/mlx5e: Add helper functions for reporter's basics
net/mlx5e: Add support to rx reporter diagnose
net/mlx5e: Split open/close ICOSQ into stages
net/mlx5e: Report and recover from CQE error on ICOSQ
net/mlx5e: Report and recover from rx timeout
net/mlx5e: Report and recover from CQE with error on RQ
Documentation: net: mlx5: Devlink health documentation updates
Gavi Teitz (1):
net/mlx5: Fix the order of fc_stats cleanup
Saeed Mahameed (1):
net/mlx5e: RX, Handle CQE with error at the earliest stage
Vlad Buslov (1):
net/mlx5e: Fix deallocation of non-fully init encap entries
.../networking/device_drivers/mellanox/mlx5.rst | 33 +-
drivers/net/ethernet/mellanox/mlx5/core/Makefile | 5 +-
drivers/net/ethernet/mellanox/mlx5/core/en.h | 32 ++
.../net/ethernet/mellanox/mlx5/core/en/health.c | 205 +++++++++++
.../net/ethernet/mellanox/mlx5/core/en/health.h | 53 +++
.../net/ethernet/mellanox/mlx5/core/en/reporter.h | 14 -
.../ethernet/mellanox/mlx5/core/en/reporter_rx.c | 404 +++++++++++++++++++++
.../ethernet/mellanox/mlx5/core/en/reporter_tx.c | 241 ++++++------
.../net/ethernet/mellanox/mlx5/core/en/xsk/setup.c | 2 +
.../net/ethernet/mellanox/mlx5/core/en/xsk/tx.c | 7 +
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 82 +++--
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 62 ++--
drivers/net/ethernet/mellanox/mlx5/core/en_stats.c | 3 +
drivers/net/ethernet/mellanox/mlx5/core/en_stats.h | 2 +
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 12 +-
.../net/ethernet/mellanox/mlx5/core/fs_counters.c | 9 +-
drivers/net/ethernet/mellanox/mlx5/core/wq.c | 5 +
drivers/net/ethernet/mellanox/mlx5/core/wq.h | 1 +
18 files changed, 965 insertions(+), 207 deletions(-)
create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en/health.c
create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en/health.h
delete mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en/reporter.h
create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en/reporter_rx.c
^ permalink raw reply
* IPv6 user level fragmentation & reassembly
From: Tran (US), Katherine K @ 2019-08-20 20:23 UTC (permalink / raw)
To: netdev@vger.kernel.org
Hello,
Would anyone have suggestions/recommendation for an existing API or program (preferably open source) that implements user level fragmentation and reassembly for IPv6?
Thanks
^ permalink raw reply
* Re: [PATCH net-next v4 1/2] dt-bindings: net: snps,dwmac: update reg minItems maxItems
From: Martin Blumenstingl @ 2019-08-20 20:17 UTC (permalink / raw)
To: Neil Armstrong
Cc: davem, robh+dt, devicetree, netdev, linux-amlogic,
linux-arm-kernel, linux-kernel, Rob Herring, Maxime Ripard
In-Reply-To: <20190820075742.14857-2-narmstrong@baylibre.com>
On Tue, Aug 20, 2019 at 9:57 AM Neil Armstrong <narmstrong@baylibre.com> wrote:
>
> The Amlogic Meson DWMAC glue bindings needs a second reg cells for the
> glue registers, thus update the reg minItems/maxItems to allow more
> than a single reg cell.
>
> Also update the allwinner,sun7i-a20-gmac.yaml derivative schema to specify
> maxItems to 1.
this looks good to me because:
- allwinner,sun7i-a20-gmac.yaml now restricts reg to maxItems 1
- allwinner,sun8i-a83t-emac.yaml already restricts reg to maxItems 1
- amlogic,meson-dwmac.yaml (introduced in patch 2 from this series)
will need maxItems 2
- (these are all yaml based schemas for DWMAC IP)
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> Acked-by: Rob Herring <robh@kernel.org>
> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
^ permalink raw reply
* Re: [PATCH][V2] net: fix __ip_mc_inc_group usage
From: David Miller @ 2019-08-20 19:48 UTC (permalink / raw)
To: lirongqing; +Cc: netdev, f.fainelli
In-Reply-To: <1566280367-8816-1-git-send-email-lirongqing@baidu.com>
From: Li RongQing <lirongqing@baidu.com>
Date: Tue, 20 Aug 2019 13:52:47 +0800
> in ip_mc_inc_group, memory allocation flag, not mcast mode, is expected
> by __ip_mc_inc_group
>
> similar issue in __ip_mc_join_group, both mcase mode and gfp_t are needed
> here, so use ____ip_mc_inc_group(...)
>
> Fixes: 9fb20801dab4 ("net: Fix ip_mc_{dec,inc}_group allocation context")
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> Signed-off-by: Zhang Yu <zhangyu31@baidu.com>
> ---
> v1-->v2:
> fixes "Fixes tag"
> use ____ip_mc_inc_group in __ip_mc_join_group
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH] vsock: Fix a lockdep warning in __vsock_release()
From: David Miller @ 2019-08-20 19:45 UTC (permalink / raw)
To: decui
Cc: jhansen, stefanha, sgarzare, netdev, sthemmin, Alexander.Levin,
sashal, haiyangz, kys, mikelley, linux-hyperv, gregkh,
linux-kernel
In-Reply-To: <1566270830-28981-1-git-send-email-decui@microsoft.com>
From: Dexuan Cui <decui@microsoft.com>
Date: Tue, 20 Aug 2019 03:14:22 +0000
> +static void __vsock_release2(struct sock *sk)
Do not duplicate an entire function just to adjust some aspect of the
lock debugging, please find a cleaner and more minimal way to
implement this fix.
^ permalink raw reply
* Re: [PATCH v2] net/ncsi: Ensure 32-bit boundary for data cksum
From: David Miller @ 2019-08-20 19:42 UTC (permalink / raw)
To: terry.s.duncan; +Cc: sam, netdev, linux-kernel, openbmc, wak, joel
In-Reply-To: <20190820002402.39001-1-terry.s.duncan@linux.intel.com>
From: "Terry S. Duncan" <terry.s.duncan@linux.intel.com>
Date: Mon, 19 Aug 2019 17:24:02 -0700
> The NCSI spec indicates that if the data does not end on a 32 bit
> boundary, one to three padding bytes equal to 0x00 shall be present to
> align the checksum field to a 32-bit boundary.
>
> Signed-off-by: Terry S. Duncan <terry.s.duncan@linux.intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH v3] ravb: implement MTU change while device is up
From: Wolfram Sang @ 2019-08-20 19:41 UTC (permalink / raw)
To: Ulrich Hecht
Cc: linux-renesas-soc, netdev, davem, sergei.shtylyov,
niklas.soderlund, horms, magnus.damm, geert
In-Reply-To: <1566327686-8996-1-git-send-email-uli+renesas@fpond.eu>
[-- Attachment #1: Type: text/plain, Size: 1745 bytes --]
Hi Uli,
thanks for the patch.
On Tue, Aug 20, 2019 at 09:01:26PM +0200, Ulrich Hecht wrote:
> Uses the same method as various other drivers: shut the device down,
> change the MTU, then bring it back up again.
>
> Tested on Renesas D3 Draak and M3-W Salvator-X boards.
>
> Signed-off-by: Ulrich Hecht <uli+renesas@fpond.eu>
> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Are these reviews left from v2? If so, I'd prefer to see them given
again because the logic was changed in v3.
> ---
>
> Hi!
>
> This revision reverts the MTU change if re-opening the device fails.
>
> CU
> Uli
>
>
> drivers/net/ethernet/renesas/ravb_main.c | 14 +++++++++++++-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
> index ef8f089..402bcec 100644
> --- a/drivers/net/ethernet/renesas/ravb_main.c
> +++ b/drivers/net/ethernet/renesas/ravb_main.c
> @@ -1810,12 +1810,24 @@ static int ravb_do_ioctl(struct net_device *ndev, struct ifreq *req, int cmd)
>
> static int ravb_change_mtu(struct net_device *ndev, int new_mtu)
> {
> + unsigned int old_mtu = ndev->mtu;
> +
> if (netif_running(ndev))
> - return -EBUSY;
> + ravb_close(ndev);
>
> ndev->mtu = new_mtu;
> netdev_update_features(ndev);
>
> + if (netif_running(ndev)) {
> + int err = ravb_open(ndev);
> +
> + if (err) {
> + ndev->mtu = old_mtu;
> + netdev_update_features(ndev);
> + return err;
> + }
> + }
> +
> return 0;
> }
>
> --
> 2.7.4
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 3/6] net: dsa: Delete the VID from the upstream port as well
From: Florian Fainelli @ 2019-08-20 19:40 UTC (permalink / raw)
To: Vivien Didelot, Vladimir Oltean
Cc: Andrew Lunn, Ido Schimmel, Roopa Prabhu, nikolay, David S. Miller,
netdev
In-Reply-To: <20190820135213.GB11752@t480s.localdomain>
On 8/20/19 10:52 AM, Vivien Didelot wrote:
> Hi Vladimir,
>
> On Tue, 20 Aug 2019 12:54:44 +0300, Vladimir Oltean <olteanv@gmail.com> wrote:
>> I can agree that this isn't one of my brightest moments. But at least
>> we get to see Cunningham's law in action :)
>> When dsa_8021q is cleaning up the switch's VLAN table for the bridge
>> to use it, it is good to really clean it up, i.e. not leave any VLAN
>> installed on the upstream ports.
>> But I think this is just an academical concern at this point. In
>> vlan_filtering mode, the CPU port will accept VLAN frames with the
>> dsa_8021q ID's, but they will eventually get dropped due to no
>> destination. The real breaker is the pvid change. If something like
>> patch 4/6 gets accepted I will drop this one.
>
> I wish Ward had mentioned to submit such academical concern as RFC :)
>
> Please submit smaller series, targeting a single functional problem each,
> with clear and detailed messages.
Also, I don't think this change set is useful per-se, if we take care of
removing VLANs on user facing ports, and VLAN filtering is turned on,
then a frame ingressing an user port with a VLAN that is not part of the
VLAN table/entries should simply be discarded on ingress, or on egress
to the CPU port (depending on where the switch performs VID checking),
so the CPU port cannot possibly receive such a frame, and so removing it
from the CPU port is correct from a reference counting perspective, but
useless in practice. Thoughts?
--
Florian
^ permalink raw reply
* Re: [PATCH spi for-5.4 1/5] spi: Use an abbreviated pointer to ctlr->cur_msg in __spi_pump_messages
From: Vladimir Oltean @ 2019-08-20 19:36 UTC (permalink / raw)
To: Mark Brown
Cc: Hubert Feurstein, mlichvar, Richard Cochran, Andrew Lunn,
Florian Fainelli, linux-spi, netdev
In-Reply-To: <20190820182128.GH4738@sirena.co.uk>
Hi Mark,
On Tue, 20 Aug 2019 at 21:21, Mark Brown <broonie@kernel.org> wrote:
>
> On Sun, Aug 18, 2019 at 09:25:56PM +0300, Vladimir Oltean wrote:
>
> > /* Extract head of queue */
> > - ctlr->cur_msg =
> > - list_first_entry(&ctlr->queue, struct spi_message, queue);
> > + mesg = list_first_entry(&ctlr->queue, struct spi_message, queue);
> > + ctlr->cur_msg = mesg;
>
> Why mesg when the existing code uses msg as an abbreviation here?
Does it matter? I took from spi_finalize_current_message which also uses mesg.
^ permalink raw reply
* Re: [PATCH net-next v2 0/6] net: dsa: enable and disable all ports
From: David Miller @ 2019-08-20 19:34 UTC (permalink / raw)
To: vivien.didelot; +Cc: netdev, marek.behun, f.fainelli, andrew
In-Reply-To: <20190819200053.21637-1-vivien.didelot@gmail.com>
From: Vivien Didelot <vivien.didelot@gmail.com>
Date: Mon, 19 Aug 2019 16:00:47 -0400
> The DSA stack currently calls the .port_enable and .port_disable switch
> callbacks for slave ports only. However, it is useful to call them for all
> port types. For example this allows some drivers to delay the optimization
> of power consumption after the switch is setup. This can also help reducing
> the setup code of drivers a bit.
>
> The first DSA core patches enable and disable all ports of a switch, regardless
> their type. The last mv88e6xxx patches remove redundant code from the driver
> setup and the said callbacks, now that they handle SERDES power for all ports.
>
> Changes in v2: do not guard .port_disable for broadcom switches.
Series applied, thanks Vivien.
^ permalink raw reply
* Re: [PATCH net-next,v2 2/6] PCI: hv: Add a Hyper-V PCI interface driver for software backchannel interface
From: David Miller @ 2019-08-20 19:29 UTC (permalink / raw)
To: haiyangz
Cc: sashal, saeedm, leon, eranbe, lorenzo.pieralisi, bhelgaas,
linux-pci, linux-hyperv, netdev, kys, sthemmin, linux-kernel
In-Reply-To: <1566242976-108801-3-git-send-email-haiyangz@microsoft.com>
From: Haiyang Zhang <haiyangz@microsoft.com>
Date: Mon, 19 Aug 2019 19:30:47 +0000
> +static void __exit exit_hv_pci_intf(void)
> +{
> + pr_info("unloaded\n");
> +}
> +
> +static int __init init_hv_pci_intf(void)
> +{
> + pr_info("loaded\n");
> +
Clogging up the logs with useless messages like this is inappropriate.
Please remove these pr_info() calls.
Also, all of these symbols should probably be GPL exported.
^ permalink raw reply
* Re: [net PATCH] net/smc: make sure EPOLLOUT is raised
From: David Miller @ 2019-08-20 19:25 UTC (permalink / raw)
To: jbaron; +Cc: netdev, edumazet, ubraun, kgraul
In-Reply-To: <1566239761-30252-1-git-send-email-jbaron@akamai.com>
From: Jason Baron <jbaron@akamai.com>
Date: Mon, 19 Aug 2019 14:36:01 -0400
> Currently, we are only explicitly setting SOCK_NOSPACE on a write timeout
> for non-blocking sockets. Epoll() edge-trigger mode relies on SOCK_NOSPACE
> being set when -EAGAIN is returned to ensure that EPOLLOUT is raised.
> Expand the setting of SOCK_NOSPACE to non-blocking sockets as well that can
> use SO_SNDTIMEO to adjust their write timeout. This mirrors the behavior
> that Eric Dumazet introduced for tcp sockets.
>
> Signed-off-by: Jason Baron <jbaron@akamai.com>
Applied and queued up for -stable, thanks Jason.
^ permalink raw reply
* Re: [PATCH v2 net-next 0/1] Add BASE-T1 PHY support
From: David Miller @ 2019-08-20 19:22 UTC (permalink / raw)
To: christian.herber; +Cc: andrew, f.fainelli, hkallweit1, netdev, linux-kernel
In-Reply-To: <20190819151940.27756-1-christian.herber@nxp.com>
From: Christian Herber <christian.herber@nxp.com>
Date: Mon, 19 Aug 2019 15:19:52 +0000
> v1 patchset can be found here: https://lkml.org/lkml/2019/8/15/626
Please expand and clarify your commit messages as requested by Heiner
in his feedback to v1.
^ permalink raw reply
* Re: [PATCH net-next 0/2] netfilter: payload mangling offload support
From: Jakub Kicinski @ 2019-08-20 19:22 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: netfilter-devel, davem, netdev, jiri, vladbu
In-Reply-To: <20190820104807.13843-1-pablo@netfilter.org>
On Tue, 20 Aug 2019 12:48:05 +0200, Pablo Neira Ayuso wrote:
> Hi,
>
> This patchset adds payload mangling offload support for Netfilter:
>
> 1) Adapt existing drivers to allow for mangling up to four 32-bit words
> with one single flow_rule action. Hence, once single action can be
> used to mangle an IPv6 address.
>
> 2) Add support for netfilter packet mangling.
Why pick 128b as a unit, because that's nftables' word size? :/
Reality is unless core coalesces _all_ consecutive rewrites drivers
will have to do their own coalescing, anyway.
We suffered through enough haphazard "updates", I don't like this either.
^ permalink raw reply
* Re: [PATCHv2 0/2] fix dev null pointer dereference when send pkg larger than mtu in collect_md mode
From: David Miller @ 2019-08-20 19:20 UTC (permalink / raw)
To: liuhangbin; +Cc: netdev, sbrivio, wenxu, ast, eric.dumazet
In-Reply-To: <20190819075327.32412-1-liuhangbin@gmail.com>
From: Hangbin Liu <liuhangbin@gmail.com>
Date: Mon, 19 Aug 2019 15:53:25 +0800
> Subject: [PATCHv2 0/2] fix dev null pointer dereference when send pkg larger than mtu in collect_md mode
Please don't use the word "package" or the shorthand "pkg" when referring
to network packets. Always use the full word "packets".
Please fix this up for your entire submission.
Thank you.
^ permalink raw reply
* Re: [PATCH net-next v2] r8152: divide the tx and rx bottom functions
From: David Miller @ 2019-08-20 19:19 UTC (permalink / raw)
To: hayeswang; +Cc: netdev, nic_swsd, linux-kernel
In-Reply-To: <1394712342-15778-303-Taiwan-albertk@realtek.com>
From: Hayes Wang <hayeswang@realtek.com>
Date: Mon, 19 Aug 2019 14:40:36 +0800
> Move the tx bottom function from NAPI to a new tasklet. Then, for
> multi-cores, the bottom functions of tx and rx may be run at same
> time with different cores. This is used to improve performance.
>
> On x86, Tx/Rx 943/943 Mbits/sec -> 945/944.
> For arm platform, Tx/Rx: 917/917 Mbits/sec -> 933/933.
>
> Signed-off-by: Hayes Wang <hayeswang@realtek.com>
> ---
> v2: add the performance number in the commit message.
Applied.
^ permalink raw reply
* [PATCH v3] ravb: implement MTU change while device is up
From: Ulrich Hecht @ 2019-08-20 19:01 UTC (permalink / raw)
To: linux-renesas-soc
Cc: netdev, davem, sergei.shtylyov, niklas.soderlund, wsa, horms,
magnus.damm, geert, Ulrich Hecht
Uses the same method as various other drivers: shut the device down,
change the MTU, then bring it back up again.
Tested on Renesas D3 Draak and M3-W Salvator-X boards.
Signed-off-by: Ulrich Hecht <uli+renesas@fpond.eu>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Hi!
This revision reverts the MTU change if re-opening the device fails.
CU
Uli
drivers/net/ethernet/renesas/ravb_main.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
index ef8f089..402bcec 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -1810,12 +1810,24 @@ static int ravb_do_ioctl(struct net_device *ndev, struct ifreq *req, int cmd)
static int ravb_change_mtu(struct net_device *ndev, int new_mtu)
{
+ unsigned int old_mtu = ndev->mtu;
+
if (netif_running(ndev))
- return -EBUSY;
+ ravb_close(ndev);
ndev->mtu = new_mtu;
netdev_update_features(ndev);
+ if (netif_running(ndev)) {
+ int err = ravb_open(ndev);
+
+ if (err) {
+ ndev->mtu = old_mtu;
+ netdev_update_features(ndev);
+ return err;
+ }
+ }
+
return 0;
}
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next 1/2] net: flow_offload: mangle 128-bit packet field with one action
From: Pablo Neira Ayuso @ 2019-08-20 18:35 UTC (permalink / raw)
To: Edward Cree; +Cc: netfilter-devel, davem, netdev, jakub.kicinski, jiri, vladbu
In-Reply-To: <f4cf8a97-3322-d982-6068-d4c0ce997b1c@solarflare.com>
On Tue, Aug 20, 2019 at 07:15:10PM +0100, Edward Cree wrote:
> On 20/08/2019 18:33, Pablo Neira Ayuso wrote:
> > I can update tc pedit to generate one single action for offset
> > consecutive packet editions, if that is the concern, I'll send a v2.
> IMHO the fix belongs in TC userland (i.e. iproute2), to turn a
> single action on the commandline for an ipv6 addr into four pedit
> actions before the kernel ever sees it.
> Similarly if nftables wants to use this it should generate four
> separate pedit actions, probably in the kernel netfilter code as (I
> assume) your uAPI talks in terms of named fields rather than the
> u32ish offsets and masks of tc pedit.
The driver flow_offload API does not necessarily need to map 1:1 to
the netlink control plane / UAPI. The driver flow_offload API is
detached from UAPI and it is internal to drivers.
> The TC (well, flow_offload now I suppose) API should be kept narrow,
> not widened for things that can already be expressed adequately.
> Your array of words inside a pedit action looks like a kind of loop
> unrolling but for data structures, which doesn't look sensible to
> me.
With one action that says "mangle an IPv6 at offset ip6 daddr field"
the driver has more global view on what is going on, rather than
having four actions to mangle four 32-bit words at some offset.
If this patch adds some loops here is because I did not want to make
too smart changes on the drivers.
The only reason I can find why mangling is restricted to 32-bits word
is tc pedit. The existing flow_offload API was modeled after tc
actions, which was exposing tc pedit implementation details to
hardware.
Please, allow for incremental updates on the flow_offload API to get
it better now. Later we'll have way more drivers it will become harder
to update this.
^ permalink raw reply
* VRF notes when using ipv6 and flushing tables.
From: Ben Greear @ 2019-08-20 18:27 UTC (permalink / raw)
To: netdev
I recently spend a few days debugging what in the end was user error on my part.
Here are my notes in hope they help someone else.
First, 'ip -6 route show vrf vrfX' will not show some of the
routes (like local routes) that will show up with
'ip -6 route show table X', where X == vrfX's table-id
If you run 'ip -6 route flush table X', then you will loose all of the auto
generated routes, including anycast, ff00::/8, and local routes.
ff00::/8 is needed for neigh discovery to work (probably among other things)
local route is needed or packets won't actually be accepted up the stack
(I think that is the symptom at least)
Not sure exactly what anycast does, but I'm guessing it is required for
something useful.
You must manually re-add those to the table unless you for certain know that
you do not need them for whatever reason.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH spi for-5.4 1/5] spi: Use an abbreviated pointer to ctlr->cur_msg in __spi_pump_messages
From: Mark Brown @ 2019-08-20 18:21 UTC (permalink / raw)
To: Vladimir Oltean
Cc: h.feurstein, mlichvar, richardcochran, andrew, f.fainelli,
linux-spi, netdev
In-Reply-To: <20190818182600.3047-2-olteanv@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 345 bytes --]
On Sun, Aug 18, 2019 at 09:25:56PM +0300, Vladimir Oltean wrote:
> /* Extract head of queue */
> - ctlr->cur_msg =
> - list_first_entry(&ctlr->queue, struct spi_message, queue);
> + mesg = list_first_entry(&ctlr->queue, struct spi_message, queue);
> + ctlr->cur_msg = mesg;
Why mesg when the existing code uses msg as an abbreviation here?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: flow_offload: mangle 128-bit packet field with one action
From: Edward Cree @ 2019-08-20 18:15 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: netfilter-devel, davem, netdev, jakub.kicinski, jiri, vladbu
In-Reply-To: <20190820173344.3nrzfjboyztz3lji@salvia>
On 20/08/2019 18:33, Pablo Neira Ayuso wrote:
> I can update tc pedit to generate one single action for offset
> consecutive packet editions, if that is the concern, I'll send a v2.
IMHO the fix belongs in TC userland (i.e. iproute2), to turn a single action on the commandline for an ipv6 addr into four pedit actions before the kernel ever sees it.
Similarly if nftables wants to use this it should generate four separate pedit actions, probably in the kernel netfilter code as (I assume) your uAPI talks in terms of named fields rather than the u32ish offsets and masks of tc pedit.
The TC (well, flow_offload now I suppose) API should be kept narrow, not widened for things that can already be expressed adequately. Your array of words inside a pedit action looks like a kind of loop unrolling but for data structures, which doesn't look sensible to me.
-Ed
^ permalink raw reply
* Re: linux-next: Tree for Aug 19 (drivers/net/netdevsim/dev.o)
From: Ido Schimmel @ 2019-08-20 18:13 UTC (permalink / raw)
To: Randy Dunlap
Cc: Stephen Rothwell, Linux Next Mailing List,
Linux Kernel Mailing List, netdev@vger.kernel.org
In-Reply-To: <92ef45a5-c933-0493-b2ff-50352fa8bf3f@infradead.org>
On Mon, Aug 19, 2019 at 09:16:13PM -0700, Randy Dunlap wrote:
> On 8/19/19 2:18 AM, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20190816:
> >
>
> on x86_64:
> # CONFIG_INET is not set
>
> ld: drivers/net/netdevsim/dev.o: in function `nsim_dev_trap_report_work':
> dev.c:(.text+0x52f): undefined reference to `ip_send_check'
>
>
> Full randconfig file is attached.
Randy,
YueHaibing sent a v2 which is available here [1]. Successfully tested
it with your config.
[1] https://patchwork.ozlabs.org/patch/1150183/
^ permalink raw reply
* Re: [PATCH v2 net-next] netdevsim: Fix build error without CONFIG_INET
From: Ido Schimmel @ 2019-08-20 18:10 UTC (permalink / raw)
To: YueHaibing
Cc: davem, idosch, jiri, mcroce, jakub.kicinski, linux-kernel, netdev
In-Reply-To: <20190820141446.71604-1-yuehaibing@huawei.com>
On Tue, Aug 20, 2019 at 10:14:46PM +0800, YueHaibing wrote:
> If CONFIG_INET is not set, building fails:
>
> drivers/net/netdevsim/dev.o: In function `nsim_dev_trap_report_work':
> dev.c:(.text+0x67b): undefined reference to `ip_send_check'
>
> Use ip_fast_csum instead of ip_send_check to avoid
> dependencies on CONFIG_INET.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Fixes: da58f90f11f5 ("netdevsim: Add devlink-trap support")
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
Tested-by: Ido Schimmel <idosch@mellanox.com>
Thanks for fixing this in my stead!
^ permalink raw reply
* Re: [PATCH v2 0/2] Simplify mtty driver and mdev core
From: Cornelia Huck @ 2019-08-20 17:55 UTC (permalink / raw)
To: Alex Williamson
Cc: Parav Pandit, Jiri Pirko, David S . Miller, Kirti Wankhede,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
cjia@nvidia.com, netdev@vger.kernel.org
In-Reply-To: <20190820111904.75515f58@x1.home>
On Tue, 20 Aug 2019 11:19:04 -0600
Alex Williamson <alex.williamson@redhat.com> wrote:
> What about an alias based on the uuid? For example, we use 160-bit
> sha1s daily with git (uuids are only 128-bit), but we generally don't
> reference git commits with the full 20 character string. Generally 12
> characters is recommended to avoid ambiguity. Could mdev automatically
> create an abbreviated sha1 alias for the device? If so, how many
> characters should we use and what do we do on collision? The colliding
> device could add enough alias characters to disambiguate (we likely
> couldn't re-alias the existing device to disambiguate, but I'm not sure
> it matters, userspace has sysfs to associate aliases). Ex.
>
> UUID=$(uuidgen)
> ALIAS=$(echo $UUID | sha1sum | colrm 13)
>
> Since there seems to be some prefix overhead, as I ask about above in
> how many characters we actually have to work with in IFNAMESZ, maybe we
> start with 8 characters (matching your "index" namespace) and expand as
> necessary for disambiguation. If we can eliminate overhead in
> IFNAMESZ, let's start with 12. Thanks,
>
> Alex
I really like that idea, and it seems the best option proposed yet, as
we don't need to create a secondary identifier.
^ permalink raw reply
* Re: [PATCH rdma-next 0/3] RDMA RX RoCE Steering Support
From: Doug Ledford @ 2019-08-20 17:54 UTC (permalink / raw)
To: Leon Romanovsky, Jason Gunthorpe
Cc: Leon Romanovsky, RDMA mailing list, Mark Bloch, Mark Zhang,
Saeed Mahameed, linux-netdev
In-Reply-To: <20190819113626.20284-1-leon@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 677 bytes --]
On Mon, 2019-08-19 at 14:36 +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@mellanox.com>
>
> Hi,
>
> This series from Mark extends mlx5 with RDMA_RX RoCE flow steering
> support
> for DEVX and QP objects.
>
> Thanks
>
> Mark Zhang (3):
> net/mlx5: Add per-namespace flow table default miss action support
> net/mlx5: Create bypass and loopback flow steering namespaces for
> RDMA
> RX
> RDMA/mlx5: RDMA_RX flow type support for user applications
I have no objection to this series.
--
Doug Ledford <dledford@redhat.com>
GPG KeyID: B826A3330E572FDD
Fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox