Discussion:
[dpdk-dev] Regarding UDP checksum offload
Prashant Upadhyaya
2015-01-28 11:25:00 UTC
Permalink
Hi,

I am aware that this topic has been discussed several times before, but I
am somehow still stuck with this.

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.

Regards
-Prashant
Olivier MATZ
2015-01-28 13:02:43 UTC
Permalink
Hi Prashant,
Post by Prashant Upadhyaya
Hi,
I am aware that this topic has been discussed several times before, but I
am somehow still stuck with this.
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?

I think you should try to reproduce the issue with the latest DPDK
which is known to work with test-pmd (csum forward engine).

Regards,
Olivier
Prashant Upadhyaya
2015-01-28 14:57:37 UTC
Permalink
Post by Olivier MATZ
Hi Prashant,
Post by Prashant Upadhyaya
Hi,
I am aware that this topic has been discussed several times before, but I
am somehow still stuck with this.
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.

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
Post by Olivier MATZ
I think you should try to reproduce the issue with the latest DPDK
which is known to work with test-pmd (csum forward engine).
Regards,
Olivier
Olivier MATZ
2015-01-28 15:09:09 UTC
Permalink
Hi Prashant,
Post by Prashant Upadhyaya
Post by Olivier MATZ
Post by Prashant Upadhyaya
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).
Post by Prashant Upadhyaya
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.

Regards,
Olivier
Prashant Upadhyaya
2015-01-29 12:56:34 UTC
Permalink
Hi Olivier,
Post by Olivier MATZ
Hi Prashant,
Post by Prashant Upadhyaya
I am using dpdk 1.6r1, intel 82599 NIC.
Post by Olivier MATZ
Post by Prashant Upadhyaya
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
Post by Prashant Upadhyaya
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 ?
Post by Olivier MATZ
Regards,
Olivier
Olivier MATZ
2015-01-30 09:15:48 UTC
Permalink
Hi,
Post by Olivier MATZ
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 ?
Only the first mbuf is required. This is the case for all offload
infos like flags, tso, ... and it's the same in rx.

Regards,
Olivier

Continue reading on narkive:
Loading...