Re: [PATCH net] net/mlx5e: fix csum adjustments caused by RXFCS

ixes: 902a545904c7 ("net/mlx5e: When RXFCS is set, add FCS data into > checksum calculation") > Reported-by: Paweł Staszewski > Signed-off-by: Eric Dumazet > Cc: Eran Ben Elisha > Cc: Saeed Mahameed > Cc: Dimitris Michailidis > Cc: Cong Wang > Cc: Paweł Staszewski

Re: bond: take rcu lock in netpoll_send_skb_on_dev

On 10/18/2018 8:46 AM, Cong Wang wrote: > On Mon, Oct 15, 2018 at 4:36 AM Eran Ben Elisha wrote: >> Hi, >> >> This suggested fix introduced a regression while using netconsole module >> with mlx5_core module loaded. > > It is already reported here: &g

Re: bond: take rcu lock in netpoll_send_skb_on_dev

On 9/28/2018 11:26 PM, Dave Jones wrote: > The bonding driver lacks the rcu lock when it calls down into > netdev_lower_get_next_private_rcu from bond_poll_controller, which > results in a trace like: > > WARNING: CPU: 2 PID: 179 at net/core/dev.c:6567 >

[PATCH ethtool v2] ethtool: Fix uninitialized variable use at qsfp dump

: a5e73bb05ee4 ("ethtool:QSFP Plus/QSFP28 Diagnostics Information Support") Signed-off-by: Eran Ben Elisha --- qsfp.c| 2 +- sfpdiag.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/qsfp.c b/qsfp.c index 32e195d12dc0..d196aa1753de 100644 --- a/qsfp.c +++ b/qsfp.c @@ -67

Re: [PATCH ethtool] ethtool: Fix uninitialized variable use at qsfp dump

On 9/27/2018 7:08 PM, Andrew Lunn wrote: > On Thu, Sep 27, 2018 at 04:48:35PM +0300, Eran Ben Elisha wrote: >> Struct sff_diags can be used uninitialized at sff8636_show_dom, this >> caused the tool to show unreported fields (supports_alarms) by the lower >> leve

Re: bug: 'ethtool -m' reports spurious alarm & warning threshold values for QSFP28 transceivers

On Thu, Sep 27, 2018 at 6:34 PM Andrew Lunn wrote: > > > Driver return 256 bytes (reading it correctly, I verified it, no overruns), > > however the extra bytes are presented due to this bug (expecting to parse > > 640 bytes). > > > > Do you see another bug here? Am I missing something? > > Hi

Re: bug: 'ethtool -m' reports spurious alarm & warning threshold values for QSFP28 transceivers

On 9/27/2018 5:52 PM, Andrew Lunn wrote: Both drivers read up to 256 bytes. 0-127 (from page 0). and 128-256 (from page 0). Driver is not capable of reading over 256 bytes currently. Hi Erin There should not be any need to read more than 256 bytes. For older SFP devices, two addresses on

Re: [RFC PATCH iproute2-next V2] System specification exception API

On 9/27/2018 5:34 PM, Jiri Pirko wrote: Thu, Sep 27, 2018 at 04:02:48PM CEST, era...@mellanox.com wrote: On 9/27/2018 3:47 PM, Jiri Pirko wrote: Wed, Sep 26, 2018 at 01:52:58PM CEST, era...@mellanox.com wrote: The exception spec is targeted for Real Time Alerting, in order to know when

Re: [RFC PATCH iproute2-next V2] System specification exception API

nditions and actions. V2: * Renaming terms: health -> exception sensor -> condition * Remove reinit command and merge with action command. * Consmetics in grammer. Eran Ben Elisha (1): man: Add devlink exception man page man/man8

[PATCH ethtool] ethtool: Fix uninitialized variable use at qsfp dump

Struct sff_diags can be used uninitialized at sff8636_show_dom, this caused the tool to show unreported fields (supports_alarms) by the lower level driver. Fixes: a5e73bb05ee4 ("ethtool:QSFP Plus/QSFP28 Diagnostics Information Support") Signed-off-by: Eran Ben Elisha --- qsfp.c | 2

Re: bug: 'ethtool -m' reports spurious alarm & warning threshold values for QSFP28 transceivers

This is just a drive by guess, but I think this is a driver issue. Issue 1 seems like a red herring, cat doesn't modify output, nor does ethtool know if its output is going to a console or a pipe, its all the same. And given issue 2 (that the output of the thresholds, etc are spurriously

[RFC PATCH iproute2-next V2] System specification exception API

: * Renaming terms: health -> exception sensor -> condition * Remove reinit command and merge with action command. * Consmetics in grammer. Eran Ben Elisha (1): man: Add devlink exception man page man/man8/devlink-exception.8 | 158 +++

[RFC PATCH iproute2-next V2] man: Add devlink exception man page

Add devlink-exception man page. Devlink-exception tool will control device exception attributes, conditions, actions and logging. Signed-off-by: Eran Ben Elisha --- Copy paste man output to here for easier review process of the RFC. DEVLINK

Re: [RFC PATCH iproute2-next] System specification health API

On 9/16/2018 10:57 PM, Andrew Lunn wrote: Why is this going under iproute rather than using one of the existing sensor API's. For example Intel NIC's have thermal sensors etc. Hi Stephen These are not that sort of sensors. This is part of the naming problem here. It is not really to do

Re: [RFC PATCH iproute2-next] System specification health API

On 9/16/2018 1:37 PM, Eran Ben Elisha wrote: On 9/13/2018 8:36 PM, Jakub Kicinski wrote: On Thu, 13 Sep 2018 11:18:15 +0300, Eran Ben Elisha wrote: The health spec is targeted for Real Time Alerting, in order to know when something bad had happened to a PCI device By spec you mean some

Re: [RFC PATCH iproute2-next] System specification health API

On 9/13/2018 8:36 PM, Jakub Kicinski wrote: On Thu, 13 Sep 2018 11:18:15 +0300, Eran Ben Elisha wrote: The health spec is targeted for Real Time Alerting, in order to know when something bad had happened to a PCI device By spec you mean some standards body spec you implement

Re: [RFC PATCH iproute2-next] man: Add devlink health man page

On 9/13/2018 6:12 PM, Andrew Lunn wrote: devlink health sensor set pci/:01:00.0 name TX_COMP_ERROR action reset off action dump on Sets TX_COMP_ERROR sensor parameters for a specific device. This is what I had in mind: 1. command interface error 2. command

Re: [RFC PATCH iproute2-next] man: Add devlink health man page

On 9/13/2018 4:24 PM, Andrew Lunn wrote: On Thu, Sep 13, 2018 at 03:49:37PM +0300, Eran Ben Elisha wrote: On 9/13/2018 3:08 PM, Andrew Lunn wrote: devlink health sensor set pci/:01:00.0 name TX_COMP_ERROR action reset off action dump on Sets TX_COMP_ERROR sensor

Re: [RFC PATCH iproute2-next] man: Add devlink health man page

On 9/13/2018 3:08 PM, Andrew Lunn wrote: devlink health sensor set pci/:01:00.0 name TX_COMP_ERROR action reset off action dump on Sets TX_COMP_ERROR sensor parameters for a specific device. I hope the real sensors have more understandable names. If i remember

Re: [RFC PATCH iproute2-next] man: Add devlink health man page

On 9/13/2018 1:27 PM, Tobin C. Harding wrote: On Thu, Sep 13, 2018 at 11:18:16AM +0300, Eran Ben Elisha wrote: Add devlink-health man page. Devlink-health tool will control device health attributes, sensors, actions and logging. Signed-off-by: Eran Ben Elisha

[RFC PATCH iproute2-next] man: Add devlink health man page

Add devlink-health man page. Devlink-health tool will control device health attributes, sensors, actions and logging. Signed-off-by: Eran Ben Elisha --- Copy paste man output to here for easier review process of the RFC. DEVLINK-HEALTH(8

[RFC PATCH iproute2-next] System specification health API

and actions. Eran Ben Elisha (1): man: Add devlink health man page man/man8/devlink-health.8 | 171 ++ 1 file changed, 171 insertions(+) create mode 100644 man/man8/devlink-health.8 -- 1.8.3.1

Re: [pull request][net-next 00/10] Mellanox, mlx5 and devlink updates 2018-07-31

Hi Dave, I would like to re-state that this feature was not meant to be a generic one. This feature was added in order to resolve a HW bug which exist in a small portion of our devices. Would you mind describing the HW bug in more detail? To a outside reviewer it really looks like you're

Re: [pull request][net-next 00/10] Mellanox, mlx5 and devlink updates 2018-07-31

On 8/2/2018 4:40 AM, David Miller wrote: From: Jakub Kicinski Date: Wed, 1 Aug 2018 17:00:47 -0700 On Wed, 1 Aug 2018 14:52:45 -0700, Saeed Mahameed wrote: - According to the discussion outcome, we are keeping the congestion control setting as mlx5 device specific for the current HW

Re: [net-next 10/16] net/mlx5: Support PCIe buffer congestion handling via Devlink

On 7/24/2018 10:51 PM, Jakub Kicinski wrote: The devlink params haven't been upstream even for a full cycle and already you guys are starting to use them to configure standard features like queuing. We developed the devlink params in order to support non-standard configuration only. And

Re: [net-next 10/16] net/mlx5: Support PCIe buffer congestion handling via Devlink

On 7/19/2018 4:49 AM, Jakub Kicinski wrote: On Wed, 18 Jul 2018 18:01:01 -0700, Saeed Mahameed wrote: +static const struct devlink_param mlx5_devlink_params[] = { + DEVLINK_PARAM_DRIVER(MLX5_DEVLINK_PARAM_ID_CONGESTION_ACTION, +"congestion_action", +

[PATCH iproute2-next] ip: Add violation counters to VF statisctics

st bcast dropped 1666 29 14 32 0 TX: bytes packets dropped 2880 44 2412 Signed-off-by: Eran Ben Elisha --- ip/ipaddress.c | 20 ++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git a/ip/ipaddress.c b/ip/ipaddre

Re: [net 4/8] net/mlx5e: Don't allow aRFS for encapsulated packets

On Thu, Jul 19, 2018 at 10:50 AM, Or Gerlitz wrote: > On Thu, Jul 19, 2018 at 9:55 AM, Eran Ben Elisha > wrote: >> On Thu, Jul 19, 2018 at 9:23 AM, Or Gerlitz wrote: >>> On Thu, Jul 19, 2018 at 4:26 AM, Saeed Mahameed wrote: >>>> From: Eran Ben Elisha >&g

Re: [net-next 10/16] net/mlx5: Support PCIe buffer congestion handling via Devlink

> > This should not be num. It should be a string. Same for "mode". will fix for v2, thanks. > >

Re: [net 4/8] net/mlx5e: Don't allow aRFS for encapsulated packets

On Thu, Jul 19, 2018 at 9:23 AM, Or Gerlitz wrote: > On Thu, Jul 19, 2018 at 4:26 AM, Saeed Mahameed wrote: >> From: Eran Ben Elisha >> >> Driver is yet to support aRFS for encapsulated packets, return early >> error in such case. > > > Eran, > >

Re: [PATCH net-next] net: ipv6/gre: Add GRO support

>>> Seems good, but why isn't this handled directly in GRO native layer ? >> ip6_tunnel and ip6_gre do not share initialization flow functions (unlike >> ipv4). >> Changing the ipv6 init infrastructure should not be part of this >> patch. we prefer to keep this one minimal, simple and safe. > > >

Re: [PATCH net-next] net: ipv6/gre: Add GRO support

On Sun, Apr 1, 2018 at 7:35 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > > > On 04/01/2018 06:17 AM, Tariq Toukan wrote: >> From: Eran Ben Elisha <era...@mellanox.com> >> >> Add GRO capability for IPv6 GRE tunnel and ip6erspan tap, via gro_cells >&

Re: xdp_router_ipv4 mellanox problem

On Mon, Jan 29, 2018 at 6:15 PM, Paweł Staszewski wrote: > Hi Hi Pawel > > Want to do some tests with xdp_router on two 100G physical interfaces but: > > Jan 29 17:00:40 HOST kernel: mlx5_core :af:00.0: MLX5E: StrdRq(0) > RqSz(1024) StrdSz(1) RxCqeCmprss(0) > Jan 29

Re: linux-next: manual merge of the net-next tree with the net tree

On Mon, Jan 15, 2018 at 1:52 AM, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the net-next tree got a conflict in: > > include/linux/mlx5/mlx5_ifc.h > > between commit: > > 8978cc921fc7 ("{net,ib}/mlx5: Don't disable local loopback multicast >

Re: [RFC PATCH net-next 0/2] Configuring PFC stall prevention via ethtool

On Thu, Nov 16, 2017 at 5:42 PM, Andrew Lunn wrote: >> I don't like adding another ethtool_ops callback tightly tied to the >> structures passed via ioctl() but when I started to think what to >> suggest as an alternative, I started to wonder if it is really necessary >> to add a

Re: [RFC PATCH net-next 0/2] Configuring PFC stall prevention via ethtool

On Thu, Nov 16, 2017 at 10:44 AM, Michal Kubecek <mkube...@suse.cz> wrote: > On Wed, Nov 15, 2017 at 09:00:09PM +0200, Eran Ben Elisha wrote: >> From: Inbar Karmy <inb...@mellanox.com> >> >> This RFC adds support for configuring PFC stall prevention through

Re: [RFC PATCH net-next 0/2] Configuring PFC stall prevention via ethtool

On Thu, Nov 16, 2017 at 4:44 AM, Andrew Lunn wrote: >> What do other vendors support? Time? Number of pause frames sent? > > So i checked a few Marvell Switches. You can also specify a time. It > is a little bit more complex than that, since the units of time depend > on the link

[RFC PATCH net-next 1/2] ethtool: Add support for configuring PFC stall prevention in ethtool

guring flow control protection mechanism into two deferent modes: default/auto. Signed-off-by: Inbar Karmy <inb...@mellanox.com> Reviewed-by: Eran Ben Elisha <era...@mellanox.com> --- include/linux/ethtool.h | 8 include/uapi/linux/ethtool.h | 20

[RFC PATCH net-next 0/2] Configuring PFC stall prevention via ethtool

From: Inbar Karmy This RFC adds support for configuring PFC stall prevention through ethtool. In the event where the device unexpectedly becomes unresponsive for a long period of time, flow control mechanism may propagate pause frames which will cause congestion spreading

[RFC PATCH net-next 2/2] net/mlx5e: PFC stall prevention support

lanox.com> Reviewed-by: Eran Ben Elisha <era...@mellanox.com> --- .../net/ethernet/mellanox/mlx5/core/en_ethtool.c | 51 drivers/net/ethernet/mellanox/mlx5/core/port.c | 56 ++ include/linux/mlx5/mlx5_ifc.h | 22 +++--

Re: mlx5 core/en oops in 4.6-rc6+

Hi Doug, Attaching here a response from Ophir Maor (from Mellanox community) > > Read your own guides ;-). > > I'm using this one for your switches: > https://community.mellanox.com/docs/DOC-1417 > > And these to try and get the linux machines configured properly: >

Re: [PATCH V2] net: ethernet: mellanox: correct page conversion

On Thu, Apr 21, 2016 at 4:39 PM, Christoph Hellwig <h...@infradead.org> wrote: > On Thu, Apr 21, 2016 at 04:37:42PM +0300, Or Gerlitz wrote: >> On Wed, Apr 20, 2016 at 9:40 PM, Eran Ben Elisha >> <eranlinuxmella...@gmail.com> wrote: >> >> It is been 1.5 year

Re: [PATCH net] net/mlx4_en: fix spurious timestamping callbacks

d47010e8 ("net/mlx4_en: Add HW timestamping (TS) support") > Signed-off-by: Eric Dumazet <eduma...@google.com> > Willem de Bruijn <will...@google.com> Other than the commit message issue raised by Or, Reviewed-by: Eran Ben Elisha <era...@mellanox.com>

Re: [PATCH V2] net: ethernet: mellanox: correct page conversion

> > It is been 1.5 years since I reported the problem. We came up with three > different solutions this week. I'd like to see a version of the solution > to get merged until Mellanox comes up with a better solution with another > patch. My proposal is to use this one. > We will post our

Re: [PATCH V2] net: ethernet: mellanox: correct page conversion

Hi Sinan, We are working in Mellanox for a solution which removes the vmap call and allocate contiguous memory (using dma_alloc_coherent). Thanks, Eran On Tue, Apr 19, 2016 at 9:37 PM, Sinan Kaya wrote: > On 4/19/2016 2:22 PM, Christoph Hellwig wrote: >> What I think we

Re: [RFC PATCH 4/5] mlx4: add support for fast rx drop bpf program

On Tue, Apr 5, 2016 at 5:20 AM, Brenden Blanco wrote: > On Sat, Apr 02, 2016 at 11:15:38PM -0700, Brenden Blanco wrote: >> On Fri, Apr 01, 2016 at 07:08:31PM -0700, Eric Dumazet wrote: > [...] >> > 2) priv->stats.rx_dropped is shared by all the RX queues -> false >> >

Re: [PATCH net-next V2 3/4] net/mlx5e: Add HW timestamping (TS) support

> +void mlx5e_fill_hwstamp(struct mlx5e_tstamp *tstamp, > + struct skb_shared_hwtstamps *hwts, > + u64 timestamp) > +{ > + unsigned long flags; > + u64 nsec; > + > + memset(hwts, 0, sizeof(struct skb_shared_hwtstamps)); > +

Re: [RFC PATCH kernel] Revert "net/mlx4_core: Add port attribute when tracking counters"

On Mon, Aug 31, 2015 at 5:39 AM, Alexey Kardashevskiy wrote: > On 08/30/2015 04:28 PM, Or Gerlitz wrote: >> >> On Fri, Aug 28, 2015 at 7:06 AM, Alexey Kardashevskiy >> wrote: >>> >>> 68230242cdb breaks SRIOV on POWER8 system. I am not really suggesting >>>