From: Tariq Toukan
Date: Mon, 20 May 2019 17:42:52 +0300
> From: Erez Alfasi
>
> Querying EEPROM high pages data for SFP module is currently
> not supported by our driver but is still tried, resulting in
> invalid FW queries.
>
> Set the EEPROM ethtool data length to 256 for SFP module to
> li
From: Erez Alfasi
Querying EEPROM high pages data for SFP module is currently
not supported by our driver but is still tried, resulting in
invalid FW queries.
Set the EEPROM ethtool data length to 256 for SFP module to
limit the reading for page 0 only and prevent invalid FW queries.
Fixes: 720
On Wed, Feb 6, 2019 at 12:17 PM Eric Dumazet wrote:
>
> On Wed, Feb 6, 2019 at 12:15 PM Saeed Mahameed
> wrote:
> >
> > Ok, just verified, csum complete (cqe->checksum) is provided and valid
> > for non-TCP/UDP ip packets, (on specific ConnectX3 HWs)
> > e.g. ICMP packets or IP fragments go throu
On Wed, Feb 6, 2019 at 12:15 PM Saeed Mahameed
wrote:
>
> Ok, just verified, csum complete (cqe->checksum) is provided and valid
> for non-TCP/UDP ip packets, (on specific ConnectX3 HWs)
> e.g. ICMP packets or IP fragments go through csum complete, that
> being said, looking at the code before my
On Thu, Jan 31, 2019 at 4:06 PM Saeed Mahameed wrote:
>
> On Thu, 2019-01-31 at 11:42 -0800, Eric Dumazet wrote:
> > On Thu, Jan 31, 2019 at 11:27 AM Saeed Mahameed
> > wrote:
> > > Are you sure ? you are claiming that the hardware will skip csum
> > > complete i.e cqe->checksum will be 0x fo
On Thu, 2019-01-31 at 11:42 -0800, Eric Dumazet wrote:
> On Thu, Jan 31, 2019 at 11:27 AM Saeed Mahameed
> wrote:
> > Are you sure ? you are claiming that the hardware will skip csum
> > complete i.e cqe->checksum will be 0x for padded short IP
> > frames.
> > i don't think this is the case, t
On Thu, Jan 31, 2019 at 11:27 AM Saeed Mahameed wrote:
>
> Are you sure ? you are claiming that the hardware will skip csum
> complete i.e cqe->checksum will be 0x for padded short IP frames.
> i don't think this is the case, the whole bug is that the hw does
> provide a partial cqe->checksum
On Thu, 2019-01-31 at 11:07 -0800, Eric Dumazet wrote:
> On Thu, Jan 31, 2019 at 11:04 AM Saeed Mahameed
> wrote:
> > On Thu, 2019-01-31 at 07:02 -0800, Eric Dumazet wrote:
> > > On Thu, Jan 31, 2019 at 5:04 AM Tariq Toukan > > >
> > > wrote:
> > > > From: Saeed Mahameed
> > > >
> > > > When an
On Thu, Jan 31, 2019 at 11:04 AM Saeed Mahameed wrote:
>
> On Thu, 2019-01-31 at 07:02 -0800, Eric Dumazet wrote:
> > On Thu, Jan 31, 2019 at 5:04 AM Tariq Toukan
> > wrote:
> > > From: Saeed Mahameed
> > >
> > > When an ethernet frame is padded to meet the minimum ethernet frame
> > > size, the
On Thu, 2019-01-31 at 07:02 -0800, Eric Dumazet wrote:
> On Thu, Jan 31, 2019 at 5:04 AM Tariq Toukan
> wrote:
> > From: Saeed Mahameed
> >
> > When an ethernet frame is padded to meet the minimum ethernet frame
> > size, the padding octets are not covered by the hardware checksum.
> > Fortunate
From: Tariq Toukan
Date: Thu, 31 Jan 2019 15:02:43 +0200
> From: Saeed Mahameed
>
> When an ethernet frame is padded to meet the minimum ethernet frame
> size, the padding octets are not covered by the hardware checksum.
> Fortunately the padding octets are usually zero's, which don't affect
>
On Thu, Jan 31, 2019 at 5:04 AM Tariq Toukan wrote:
>
> From: Saeed Mahameed
>
> When an ethernet frame is padded to meet the minimum ethernet frame
> size, the padding octets are not covered by the hardware checksum.
> Fortunately the padding octets are usually zero's, which don't affect
> check
From: Saeed Mahameed
When an ethernet frame is padded to meet the minimum ethernet frame
size, the padding octets are not covered by the hardware checksum.
Fortunately the padding octets are usually zero's, which don't affect
checksum. However, it is not guaranteed. For example, switches might
ch
On Tue, 2018-10-30 at 00:18 -0700, Eric Dumazet wrote:
> Abdul Haleem reported a build error on ppc :
>
> drivers/net/ethernet/mellanox/mlx4/en_rx.c:582:18: warning: `struct
> iphdr` declared inside parameter list [enabled by default]
>struct iphdr *iph)
> ^
> drivers
On 30/10/2018 8:19 PM, David Miller wrote:
> From: Eric Dumazet
> Date: Tue, 30 Oct 2018 00:18:12 -0700
>
>> Abdul Haleem reported a build error on ppc :
>>
>> drivers/net/ethernet/mellanox/mlx4/en_rx.c:582:18: warning: `struct
>> iphdr` declared inside parameter list [enabled by default]
>>
From: Eric Dumazet
Date: Tue, 30 Oct 2018 00:18:12 -0700
> Abdul Haleem reported a build error on ppc :
>
> drivers/net/ethernet/mellanox/mlx4/en_rx.c:582:18: warning: `struct
> iphdr` declared inside parameter list [enabled by default]
>struct iphdr *iph)
> ^
> dri
Abdul Haleem reported a build error on ppc :
drivers/net/ethernet/mellanox/mlx4/en_rx.c:582:18: warning: `struct
iphdr` declared inside parameter list [enabled by default]
struct iphdr *iph)
^
drivers/net/ethernet/mellanox/mlx4/en_rx.c:582:18: warning: its scope is
onl
From: Tariq Toukan
Date: Sun, 15 Jul 2018 13:54:39 +0300
> From: Saeed Mahameed
>
> When a new rx packet arrives, the rx path will decide whether to reuse
> the remainder of the page or not according to one of the below conditions:
> 1. frag_info->frag_stride == PAGE_SIZE / 2
> 2. frags->page_o
From: Saeed Mahameed
When a new rx packet arrives, the rx path will decide whether to reuse
the remainder of the page or not according to one of the below conditions:
1. frag_info->frag_stride == PAGE_SIZE / 2
2. frags->page_offset + frag_info->frag_size > PAGE_SIZE;
The first condition is no me
From: Tariq Toukan
Date: Wed, 9 May 2018 18:35:13 +0300
> From: Moshe Shemesh
>
> Add check of coalescing parameters received through ethtool are within
> range of values supported by the HW.
> Driver gets the coalescing rx/tx-usecs and rx/tx-frames as set by the
> users through ethtool. The e
From: Moshe Shemesh
Add check of coalescing parameters received through ethtool are within
range of values supported by the HW.
Driver gets the coalescing rx/tx-usecs and rx/tx-frames as set by the
users through ethtool. The ethtool support up to 32 bit value for each.
However, mlx4 modify cq lim
From: Eric Dumazet
Date: Thu, 23 Feb 2017 15:22:43 -0800
> From: Eric Dumazet
>
> The cited commit makes a great job of finding optimal shift/multiplier
> values assuming a 10 seconds wrap around, but forgot to change the
> overflow_period computation.
>
> It overflows in cyclecounter_cyc2ns()
On 24/02/2017 1:22 AM, Eric Dumazet wrote:
From: Eric Dumazet
The cited commit makes a great job of finding optimal shift/multiplier
values assuming a 10 seconds wrap around, but forgot to change the
overflow_period computation.
It overflows in cyclecounter_cyc2ns(), and the final result is
On Sun, 2017-02-26 at 09:40 -0800, Eric Dumazet wrote:
> NAPI_STATE_SCHED
>
> Actually we could use an additional bit for that, that the driver would
> set even if NAPI_STATE_SCHED could not be grabbed.
Just to be clear :
Drivers would require no change, this would be done in
existing helpers.
On Sun, 2017-02-26 at 09:34 -0800, Eric Dumazet wrote:
> I do not believe this bug is mlx4 specific.
>
> Anything doing the following while hard irq were not masked :
>
> local_bh_disable();
> napi_reschedule(&priv->rx_cq[ring]->napi);
> local_bh_enable();
>
> Like in mlx4_en_recover_from_oom()
On Sun, 2017-02-26 at 18:32 +0200, Saeed Mahameed wrote:
> On Sat, Feb 25, 2017 at 4:22 PM, Eric Dumazet wrote:
> > From: Eric Dumazet
> >
> > While playing with hardware timestamping of RX packets, I found
> > that some packets were received by TCP stack with a ~200 ms delay...
> >
> > Since the
On Sat, Feb 25, 2017 at 4:22 PM, Eric Dumazet wrote:
> From: Eric Dumazet
>
> While playing with hardware timestamping of RX packets, I found
> that some packets were received by TCP stack with a ~200 ms delay...
>
> Since the timestamp was provided by the NIC, and my probe was added
> in tcp_v4_
On Fri, Feb 24, 2017 at 6:21 PM, David Miller wrote:
> From: Eric Dumazet
> Date: Thu, 23 Feb 2017
> Tariq please review.
Dave,
Just to re-iterate what we wrote here couple of time, the IL WW is
Sun-Thu on GMT+2 hours and hence this patch was sent when the
developers/maintainer are into weeken
From: Eric Dumazet
While playing with hardware timestamping of RX packets, I found
that some packets were received by TCP stack with a ~200 ms delay...
Since the timestamp was provided by the NIC, and my probe was added
in tcp_v4_rcv() while in BH handler, I was confident it was not
a sender iss
From: Eric Dumazet
Date: Thu, 23 Feb 2017 15:22:43 -0800
> From: Eric Dumazet
>
> The cited commit makes a great job of finding optimal shift/multiplier
> values assuming a 10 seconds wrap around, but forgot to change the
> overflow_period computation.
>
> It overflows in cyclecounter_cyc2ns()
From: Eric Dumazet
The cited commit makes a great job of finding optimal shift/multiplier
values assuming a 10 seconds wrap around, but forgot to change the
overflow_period computation.
It overflows in cyclecounter_cyc2ns(), and the final result is 804 ms,
which is silly.
Lets simply use 5 seco
From: Tariq Toukan
Date: Thu, 22 Dec 2016 14:32:58 +0200
> The user prio field is wrong (and overflows) in the XDP forward
> flow.
> This is a result of a bad value for num_tx_rings_p_up, which should
> account all XDP TX rings, as they operate for the same user prio.
>
> Signed-off-by: Tariq To
The user prio field is wrong (and overflows) in the XDP forward
flow.
This is a result of a bad value for num_tx_rings_p_up, which should
account all XDP TX rings, as they operate for the same user prio.
Signed-off-by: Tariq Toukan
Reported-by: Martin KaFai Lau
---
drivers/net/ethernet/mellanox
From: Tariq Toukan
Date: Tue, 22 Nov 2016 16:20:39 +0200
> Make sure mlx4_en_free_resources is called under the netdev state lock.
> This is needed since RCU dereference of XDP prog should be protected.
>
> Fixes: 326fe02d1ed6 ("net/mlx4_en: protect ring->xdp_prog with rcu_read_lock")
> Signed-o
Make sure mlx4_en_free_resources is called under the netdev state lock.
This is needed since RCU dereference of XDP prog should be protected.
Fixes: 326fe02d1ed6 ("net/mlx4_en: protect ring->xdp_prog with rcu_read_lock")
Signed-off-by: Tariq Toukan
Reported-by: Sagi Grimberg
CC: Brenden Blanco
From: Brenden Blanco
Date: Thu, 13 Oct 2016 13:13:11 -0700
> In cases where the number of tx rings is not a multiple of the number of
> rx rings, the tx completion event will be handled on a different core
> from the transmit and population of the ring. Races on the ring will
> lead to a double-f
In cases where the number of tx rings is not a multiple of the number of
rx rings, the tx completion event will be handled on a different core
from the transmit and population of the ring. Races on the ring will
lead to a double-free of the page, and possibly other corruption.
The rings are initia
From: Eric Dumazet
Date: Mon, 13 Jun 2016 07:50:25 -0700
> From: Eric Dumazet
>
> Maciej Żenczykowski reported lockdep warning a spinlock
> was not registered before being held in mlx4_cmd_wake_completions()
>
> cmd.context_lock initialization is not at the right place.
>
> 1) mlx4_cmd_use_ev
From: Eric Dumazet
Maciej Żenczykowski reported lockdep warning a spinlock
was not registered before being held in mlx4_cmd_wake_completions()
cmd.context_lock initialization is not at the right place.
1) mlx4_cmd_use_events() can be called multiple times.
Calling spin_lock_init() on a live
From: Tariq Toukan
Date: Wed, 4 May 2016 15:00:33 +0300
> From: Daniel Jurgens
>
> Use htons instead of unconditionally byte swapping nexthdr. On a little
> endian systems shifting the byte is correct behavior, but it results in
> incorrect csums on big endian architectures.
>
> Fixes: f8c64
From: Daniel Jurgens
Use htons instead of unconditionally byte swapping nexthdr. On a little
endian systems shifting the byte is correct behavior, but it results in
incorrect csums on big endian architectures.
Fixes: f8c6455bb04b ('net/mlx4_en: Extend checksum offloading by CHECKSUM
COMPLETE')
From: Eric Dumazet
Date: Sat, 23 Apr 2016 11:35:46 -0700
> From: Eric Dumazet
>
> When multiple skb are TX-completed in a row, we might incorrectly keep
> a timestamp of a prior skb and cause extra work.
>
> Fixes: ec693d47010e8 ("net/mlx4_en: Add HW timestamping (TS) support")
> Signed-off-by
On Sat, Apr 23, 2016 at 9:35 PM, Eric Dumazet wrote:
> From: Eric Dumazet
>
> When multiple skb are TX-completed in a row, we might incorrectly keep
> a timestamp of a prior skb and cause extra work.
>
> Fixes: ec693d47010e8 ("net/mlx4_en: Add HW timestamping (TS) support")
> Signed-off-by: Eric
On Sat, 2016-04-23 at 23:23 +0300, Or Gerlitz wrote:
> On Sat, Apr 23, 2016 at 9:35 PM, Eric Dumazet wrote:
> > From: Eric Dumazet
> >
> > When multiple skb are TX-completed in a row, we might incorrectly keep
> > a timestamp of a prior skb and cause extra work.
> >
> > Fixes: ec693d47010e8 ("net
On Sat, Apr 23, 2016 at 9:35 PM, Eric Dumazet wrote:
> From: Eric Dumazet
>
> When multiple skb are TX-completed in a row, we might incorrectly keep
> a timestamp of a prior skb and cause extra work.
>
> Fixes: ec693d47010e8 ("net/mlx4_en: Add HW timestamping (TS) support")
> Signed-off-by: Eric
From: Eric Dumazet
When multiple skb are TX-completed in a row, we might incorrectly keep
a timestamp of a prior skb and cause extra work.
Fixes: ec693d47010e8 ("net/mlx4_en: Add HW timestamping (TS) support")
Signed-off-by: Eric Dumazet
Willem de Bruijn
---
drivers/net/ethernet/mellanox/mlx4
Arg, patch title was meant to be
net/mlx4_en: really allow to change RSS key
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Eric Dumazet
When changing rss key, we do not want to overwrite user provided key
by the one provided by netdev_rss_key_fill(), which is the host random
key generated at boot time.
Fixes: 947cbb0ac242 ("net/mlx4_en: Support for configurable RSS hash function")
Signed-off-by: Eric Dumazet
From: Ido Shamay
When system is out of memory, refilling of RX buffers fails while
the driver continue to pass the received packets to the kernel stack.
At some point, when all RX buffers deplete, driver may fall into a
sleep, and not recover when memory for new RX buffers is once again
availible
49 matches
Mail list logo
