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
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
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
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: 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: 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
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: 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
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
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
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: 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: 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
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
34 matches
Mail list logo
