From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by dpdk.org (Postfix) with ESMTP id D1A795A7C for ; Thu, 29 Jan 2015 13:56:34 +0100 (CET) Received: by mail-wi0-f178.google.com with SMTP id bs8so15595100wib.5 for ; Thu, 29 Jan 2015 04:56:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jGQRE3f9COFbsC2xLbfs9SZzXn0Xg523dlnwnSraTQk=; b=MOb0ZViQ3cbyMiu9Mw73w1cLtJ+7687Cn0WCcscBO8T5ndScGjWj1ObkMqaHhCvpdc aiazk1avMcOyRFdrPtjK19dTlMlrQOMJHaX3/ygHTVFNRZ6UfPHl5iCV0fUk3HDD1YuD pp8jUW9aiURwOrDW8ukMJ/Ei9DPiLb8A5y8uxbO1BzcSmHOZ58jg4MiKy/UOfSCeQ3sO K01cQ+1XiJdU/wxX/g/AIKaKDgg3mDcjJX5KnemO4evHOa+eTlm65ODHAR5Lm4sszVW/ Lu4pQvkEAeIwMlDj/FmjHMW2JMybX3gCLKIgSFK/yNuNnZ7RWQW9+iz5n3Jdgw1b0bWr zbkQ== MIME-Version: 1.0 X-Received: by 10.180.92.231 with SMTP id cp7mr959720wib.24.1422536194180; Thu, 29 Jan 2015 04:56:34 -0800 (PST) Received: by 10.194.2.10 with HTTP; Thu, 29 Jan 2015 04:56:34 -0800 (PST) In-Reply-To: <54C8FB95.7040503@6wind.com> References: <54C8DDF3.2000802@6wind.com> <54C8FB95.7040503@6wind.com> Date: Thu, 29 Jan 2015 18:26:34 +0530 Message-ID: From: Prashant Upadhyaya To: Olivier MATZ Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: dev@dpdk.org Subject: Re: [dpdk-dev] Regarding UDP checksum offload X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 12:56:35 -0000 Hi Olivier, On Wed, Jan 28, 2015 at 8:39 PM, Olivier MATZ 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 > >