DPDK patches and discussions
 help / color / mirror / Atom feed
From: Prashant Upadhyaya <praupadhyaya@gmail.com>
To: Olivier MATZ <olivier.matz@6wind.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] Regarding UDP checksum offload
Date: Thu, 29 Jan 2015 18:26:34 +0530	[thread overview]
Message-ID: <CAPBAu3V6Dwt=MTauBpBU9QxySk4Rj6n5ARZ4PsvZujWQe3w1ew@mail.gmail.com> (raw)
In-Reply-To: <54C8FB95.7040503@6wind.com>

Hi Olivier,

On Wed, Jan 28, 2015 at 8:39 PM, Olivier MATZ <olivier.matz@6wind.com>
wrote:

> Hi Prashant,
>
>
> On 01/28/2015 03:57 PM, Prashant Upadhyaya wrote:
>
>>         I am using dpdk 1.6r1, intel 82599 NIC.
>>>>         I have an mbuf, I have hand-constructed a UDP packet (IPv4) in
>>>>         the data
>>>>         portion, filled the relevant fields of the headers and I do a tx
>>>>         burst. No
>>>>         problems, the destination gets the packet. I filled UDP checksum
>>>>         as zero
>>>>         and there was no checksum offloaded in ol_flags.
>>>>
>>>>         Now in the same usecase, I want to offload UDP checksum.
>>>>         I am aware that the checksum field in UDP header has to be
>>>>         filled with the
>>>>         pseudo header checksum, I did that, duly added the
>>>>         PKT_TX_UDP_CKSUM flag in
>>>>         ol_flags, did a tx_burst and the packet does not reach the
>>>>         destination.
>>>>
>>>>         I realized that I have to fill the following fields as well (my
>>>>         packet does
>>>>         not have vlan tag)
>>>>         mbuf->pkt.vlan_macip.f.l2_len
>>>>         mbuf->pkt.vlan_macip.f.l3_len
>>>>
>>>>         so I filled the l2_len as 14 and l3_len as 20 (IP header with no
>>>>         options)
>>>>         Yet the packet did not reach the destination.
>>>>
>>>>         So my question is -- am I filling the l2_len and l3_len
>>>> properly ?
>>>>         Is there anything else to be done before I can get this UDP
>>>> checksum
>>>>         offload to work properly for me.
>>>>
>>>
>>>
>>>
>>>     As far as I remember, this should be working on 1.6r1.
>>>     When you say "did not reach the destination", do you mean that the
>>>     packet is not transmitted at all? Or is it transmitted with a wrong
>>>     checksum?
>>>
>>
>>
>> The packet is not transmitted to destination. I cannot see it in tcpdump
>> at wireshark.
>> If I don't do the offload and fill UDP checksum as zero, then
>> destination shows the packet in tcpdump
>> If I don't do the offload and just fill the pseudo header checksum in
>> UDP header (clearly the wrong checksum), then the destination shows the
>> packet in tcpdump and wireshark decodes it to complain of wrong UDP
>> checksum as expected.
>>
>
> This is strange. I don't see anything obvious in what you are
> describing. It looks like the packet is dropped in the driver
> or in the hardware. You can check the device statistics.
>
> Another thing you can do is to retry on the latest stable dpdk which
> is known to work (see csumonly.c in test-pmd).
>
>  Let me add further, I am _just_ doing the UDP checksum offload and not
>> the IP hdr checksum offload. I calculate and set IP header checksum by
>> my own code. I hope that this is acceptable and does not interfere with
>> UDP checksum offload
>>
>
> This should not be a problem.
>
> Indeed it worked with DPDK1.7 and then I retried with DPDK1.6 and it
worked there too.
Must have been some mistake at my end, may be I did not clean properly when
I was experimenting with some values of l2_len.
Sorry for the botheration to the list.

While we are at it, a quick question -- in case I have an mbuf chain whose
payloads constitute a UDP packet, should I setup the ol_flags and the
l2_len, l3_len fields only in the first mbuf header of the chain or in all
the mbuf headers of the chain ?


> Regards,
> Olivier
>
>

  reply	other threads:[~2015-01-29 12:56 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-28 11:25 Prashant Upadhyaya
2015-01-28 13:02 ` Olivier MATZ
2015-01-28 14:57   ` Prashant Upadhyaya
2015-01-28 15:09     ` Olivier MATZ
2015-01-29 12:56       ` Prashant Upadhyaya [this message]
2015-01-30  9:15         ` Olivier MATZ

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAPBAu3V6Dwt=MTauBpBU9QxySk4Rj6n5ARZ4PsvZujWQe3w1ew@mail.gmail.com' \
    --to=praupadhyaya@gmail.com \
    --cc=dev@dpdk.org \
    --cc=olivier.matz@6wind.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).