[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f046dbf4-0b46-2d7c-c82c-fe9f50c11f71@cambridgegreys.com>
Date: Thu, 12 Oct 2017 15:12:52 +0100
From: Anton Ivanov <anton.ivanov@...bridgegreys.com>
To: Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc: Network Development <netdev@...r.kernel.org>
Subject: Re: BUG:af_packet fails to TX TSO frames
On 10/12/17 14:39, Willem de Bruijn wrote:
>> If I produce a real vnet frame out of a live kernel frame using
>> virtio_net_hdr_from_skb() and try to send it it fails on the check in
>> af_packet, while succeeding for tap. If I remove the af_packet check the
>> frame is accepted by the hardware too.
>>
>> If I produce it a synthetic frame + vnet header using the test program - it
>> works. Go figure.
> Besides looking at the raw frame bytes, also compare the setup
> of virtio_net_header, as well as the tcp checksum field. The stack
> expects the pseudo header to have already been calculated.
I am feeding it a skb which is coming up in the tx routine of a User
Mode Linux device which is marked as NETIF_F_HW_CSUM and SG - that
results in a skb with csum-ed headers, body set up for CSUM_PARTIAL and
multiple fragments (always at least 1 more frag besides the TCP head).
That has everything in order as expected by virtio_net_hdr_from_skb and
this is what I use to generate the vnet header. It works correctly for
csum and GRO with af_packet and it works correctly for everything using
a tap device. It fails only on GSO + af_packet TX.
What I am doing is the same thing virtio_net does - it just takes the
output of virtio_net_hdr_from_skb and does nothing more. There should be
no need to do anything more :(
It should just work.
Unless there is a gremlin somewhere in the machinery and that gremlin
needs some light to be flushed out.
>
>> I am going to continue digging into it.
>>
>> At the very least I now have a positive test case which uses the same
>> semantics as my code so I have something to compare to.
> Glad to hear that the test is helpful. I wrote it because I
> have run into these exact same issues in the past.
It is. I have changes ready for it so it also supports vector IO, need
to finish fighting with it.
A.
>
--
Anton R. Ivanov
Cambridge Greys Limited, England and Wales company No 10273661
http://www.cambridgegreys.com/
Powered by blists - more mailing lists