* [dpdk-dev] Regarding UDP checksum offload @ 2015-01-28 11:25 Prashant Upadhyaya 2015-01-28 13:02 ` Olivier MATZ 0 siblings, 1 reply; 6+ messages in thread From: Prashant Upadhyaya @ 2015-01-28 11:25 UTC (permalink / raw) To: dev 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dpdk-dev] Regarding UDP checksum offload 2015-01-28 11:25 [dpdk-dev] Regarding UDP checksum offload Prashant Upadhyaya @ 2015-01-28 13:02 ` Olivier MATZ 2015-01-28 14:57 ` Prashant Upadhyaya 0 siblings, 1 reply; 6+ messages in thread From: Olivier MATZ @ 2015-01-28 13:02 UTC (permalink / raw) To: Prashant Upadhyaya, dev Hi Prashant, On 01/28/2015 12:25 PM, Prashant Upadhyaya wrote: > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dpdk-dev] Regarding UDP checksum offload 2015-01-28 13:02 ` Olivier MATZ @ 2015-01-28 14:57 ` Prashant Upadhyaya 2015-01-28 15:09 ` Olivier MATZ 0 siblings, 1 reply; 6+ messages in thread From: Prashant Upadhyaya @ 2015-01-28 14:57 UTC (permalink / raw) To: Olivier MATZ; +Cc: dev On Wed, Jan 28, 2015 at 6:32 PM, Olivier MATZ <olivier.matz@6wind.com> wrote: > Hi Prashant, > > > On 01/28/2015 12:25 PM, Prashant Upadhyaya wrote: > >> 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 > > 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 > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dpdk-dev] Regarding UDP checksum offload 2015-01-28 14:57 ` Prashant Upadhyaya @ 2015-01-28 15:09 ` Olivier MATZ 2015-01-29 12:56 ` Prashant Upadhyaya 0 siblings, 1 reply; 6+ messages in thread From: Olivier MATZ @ 2015-01-28 15:09 UTC (permalink / raw) To: Prashant Upadhyaya; +Cc: dev 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. Regards, Olivier ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dpdk-dev] Regarding UDP checksum offload 2015-01-28 15:09 ` Olivier MATZ @ 2015-01-29 12:56 ` Prashant Upadhyaya 2015-01-30 9:15 ` Olivier MATZ 0 siblings, 1 reply; 6+ messages in thread From: Prashant Upadhyaya @ 2015-01-29 12:56 UTC (permalink / raw) To: Olivier MATZ; +Cc: dev 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 > > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [dpdk-dev] Regarding UDP checksum offload 2015-01-29 12:56 ` Prashant Upadhyaya @ 2015-01-30 9:15 ` Olivier MATZ 0 siblings, 0 replies; 6+ messages in thread From: Olivier MATZ @ 2015-01-30 9:15 UTC (permalink / raw) To: Prashant Upadhyaya; +Cc: dev Hi, On 01/29/2015 01:56 PM, Prashant Upadhyaya wrote: > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-01-30 9:15 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-01-28 11:25 [dpdk-dev] Regarding UDP checksum offload 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 2015-01-30 9:15 ` Olivier MATZ
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).