On Wed, Jun 29, 2016 at 7:23 AM, Tariq Toukan wrote:
> Hi Cong,
>
>> See below. Does commit f8c6455bb04b944edb69e rely on any firmware
>> change to get an expected checksum?
>>
>> $ lspci -nn | grep -i mellanox
>> 82:00.0 Ethernet controller [0200]: Mellanox Technologies MT27500
>> Family [Connect
On Wed, Jun 29, 2016 at 5:23 PM, Tariq Toukan wrote:
> Hi Cong,
>
>> See below. Does commit f8c6455bb04b944edb69e rely on any firmware
>> change to get an expected checksum?
>>
>> $ lspci -nn | grep -i mellanox
>> 82:00.0 Ethernet controller [0200]: Mellanox Technologies MT27500
>> Family [Connect
Hi Cong,
See below. Does commit f8c6455bb04b944edb69e rely on any firmware
change to get an expected checksum?
$ lspci -nn | grep -i mellanox
82:00.0 Ethernet controller [0200]: Mellanox Technologies MT27500
Family [ConnectX-3] [15b3:1003]
$ ethtool -i eth0
driver: mlx4_en
version: 2.2-1 (Feb
On Tue, Jun 28, 2016 at 7:30 AM, Or Gerlitz wrote:
> Wow, can you please report us the exact card type (lspci -nn | grep -i
> mellanox) and firmware version (ethtool -i $DEV)
See below. Does commit f8c6455bb04b944edb69e rely on any firmware
change to get an expected checksum?
$ lspci -nn | grep
On Tue, Jun 28, 2016 at 12:44 AM, Cong Wang wrote:
> On Mon, Jun 27, 2016 at 2:08 PM, Or Gerlitz wrote:
>> On Mon, Jun 27, 2016 at 9:22 PM, Cong Wang wrote:
>> can you point/paste the exact warning and how to reproduce that? is
>> that as simple as running ping and/or ping6?
> Yes, ping is eno
On Mon, Jun 27, 2016 at 3:53 PM, Cong Wang wrote:
> On Mon, Jun 27, 2016 at 3:04 PM, Tom Herbert wrote:
>> On Mon, Jun 27, 2016 at 2:49 PM, Cong Wang wrote:
>>> On Mon, Jun 27, 2016 at 2:47 PM, Tom Herbert wrote:
On Mon, Jun 27, 2016 at 2:44 PM, Cong Wang
wrote:
> On Mon, Jun 27
On Mon, Jun 27, 2016 at 3:04 PM, Tom Herbert wrote:
> On Mon, Jun 27, 2016 at 2:49 PM, Cong Wang wrote:
>> On Mon, Jun 27, 2016 at 2:47 PM, Tom Herbert wrote:
>>> On Mon, Jun 27, 2016 at 2:44 PM, Cong Wang wrote:
On Mon, Jun 27, 2016 at 2:08 PM, Or Gerlitz wrote:
> On Mon, Jun 27, 201
On Mon, Jun 27, 2016 at 2:49 PM, Cong Wang wrote:
> On Mon, Jun 27, 2016 at 2:47 PM, Tom Herbert wrote:
>> On Mon, Jun 27, 2016 at 2:44 PM, Cong Wang wrote:
>>> On Mon, Jun 27, 2016 at 2:08 PM, Or Gerlitz wrote:
On Mon, Jun 27, 2016 at 9:22 PM, Cong Wang
wrote:
> The stack doesn
On Mon, Jun 27, 2016 at 2:47 PM, Tom Herbert wrote:
> On Mon, Jun 27, 2016 at 2:44 PM, Cong Wang wrote:
>> On Mon, Jun 27, 2016 at 2:08 PM, Or Gerlitz wrote:
>>> On Mon, Jun 27, 2016 at 9:22 PM, Cong Wang wrote:
The stack doesn't trust the complete csum by hardware
even when it is cor
On Mon, Jun 27, 2016 at 2:44 PM, Cong Wang wrote:
> On Mon, Jun 27, 2016 at 2:08 PM, Or Gerlitz wrote:
>> On Mon, Jun 27, 2016 at 9:22 PM, Cong Wang wrote:
>>> The stack doesn't trust the complete csum by hardware
>>> even when it is correct.
>>
>> Can you explain that a little further?
>
> Sure
On Mon, Jun 27, 2016 at 2:08 PM, Or Gerlitz wrote:
> On Mon, Jun 27, 2016 at 9:22 PM, Cong Wang wrote:
>> The stack doesn't trust the complete csum by hardware
>> even when it is correct.
>
> Can you explain that a little further?
Sure, here is the code in __skb_checksum_complete():
/*
On Mon, Jun 27, 2016 at 9:22 PM, Cong Wang wrote:
> The stack doesn't trust the complete csum by hardware
> even when it is correct.
Can you explain that a little further?
> In the case we fix csum by ourself
> probably it is safe to just mark it as completed by software.
> This should shut up
The stack doesn't trust the complete csum by hardware
even when it is correct. In the case we fix csum by ourself
probably it is safe to just mark it as completed by software.
This should shut up a kernel warning from netdev_rx_csum_fault()
with mlx4 driver for ICMP packets.
Fixes: f8c6455bb04b (
13 matches
Mail list logo
