From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by dpdk.org (Postfix) with ESMTP id 686281F5 for ; Wed, 28 Jan 2015 16:09:11 +0100 (CET) Received: by mail-wi0-f180.google.com with SMTP id h11so12522008wiw.1 for ; Wed, 28 Jan 2015 07:09:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=k0nfCk0nP/laITAJezTWe1c4dpY5ic5Y9PcC39Z3yCs=; b=gQh0nZ0l9yITlNF2JEKdbYhm1yS/jgP6gftobF3SMGEx9lpzOs5HZlpEr4FC+8ZLC1 I6xopLlCTO3PrJwQNRsCtq6AQGTGQ10Uiic1h+6xhSxOfNHHn1aA8agiIAJcG6NOwJ48 8GZwxUbkTx8UCSTJptnfUufiA07DCfm6rkvm+NP0dQ3sfomMZ0PHwqcArUB9gqSaBBSg zyTFyvPUGLmFQJfd02qdXYeGeFZ5DN6wK3TCp5VvQ5NunfoS6EGJfE5FqGRqEdoX+9Mz QtKvHtQuiKH2LZ4Js/WzhT1fq8Pj9kgKbEw6kg2Sgr7rq7dvFA0lEFjLr6tZLShPCZRm OUWA== X-Gm-Message-State: ALoCoQkqAffvKjWwDNQgvQ13lGWAvTv9NVX+d18L3fWDZNpL4hYvtflkILVXcagytaP7IBI0ig5I X-Received: by 10.195.13.104 with SMTP id ex8mr5118225wjd.12.1422457751242; Wed, 28 Jan 2015 07:09:11 -0800 (PST) Received: from [10.16.0.195] (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by mx.google.com with ESMTPSA id vq9sm6495274wjc.6.2015.01.28.07.09.10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Jan 2015 07:09:10 -0800 (PST) Message-ID: <54C8FB95.7040503@6wind.com> Date: Wed, 28 Jan 2015 16:09:09 +0100 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.2.0 MIME-Version: 1.0 To: Prashant Upadhyaya References: <54C8DDF3.2000802@6wind.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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: Wed, 28 Jan 2015 15:09:11 -0000 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