From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by dpdk.org (Postfix) with ESMTP id 04CDD1F3 for ; Tue, 8 Oct 2013 09:55:33 +0200 (CEST) Received: by mail-ie0-f175.google.com with SMTP id e14so17849595iej.6 for ; Tue, 08 Oct 2013 00:56:18 -0700 (PDT) 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:content-transfer-encoding; bh=SqfHs7yThUOpqIJkrhqgkV8iGGcUnDigTm05L6gM2II=; b=dkcuM469HC3KHRXUifay/EMPcv7giq/rUXKefwlsqENoh2Zs0dorHMPkHH1wszC+YC bWQ9jxf6leSViU13Tcq0KbQZxvEQt5Z5llbXp4QyR2lihyVPGNM5qF1+E2kEaOLvBvAh d9l6phfpJT4H1MgGYpgoQHX6c8pHCtG8ARgfkV/AWktr6g7i5tmR2H2X9xxerQl6bGWE 23aZaEE/Ajh+1QH5F7v8ZdBbSF5g5wDJR7I1F4gja4sowetY3oF6WL7V5voxjlsN07xr Bid31yOk1DXP49yAcjjDs8ANs1TEwROgBx6GidthmPNBSUdeT/qqD0LGF0c0odYAJmGq H+wQ== MIME-Version: 1.0 X-Received: by 10.50.25.129 with SMTP id c1mr20418590igg.23.1381218978132; Tue, 08 Oct 2013 00:56:18 -0700 (PDT) Received: by 10.42.67.205 with HTTP; Tue, 8 Oct 2013 00:56:18 -0700 (PDT) In-Reply-To: References: <1380906413-3406-1-git-send-email-jigsaw@gmail.com> <20131004104030.206356dd@nehalam.linuxnetplumber.net> <20131004112302.50693f04@nehalam.linuxnetplumber.net> <1FD9B82B8BF2CF418D9A1000154491D973F58EE2@ORSMSX102.amr.corp.intel.com> Date: Tue, 8 Oct 2013 10:56:18 +0300 Message-ID: From: jigsaw To: "Zhu, Heqing" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH] Request for comments on ixgbe TSO support 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: Tue, 08 Oct 2013 07:55:34 -0000 Hi Heqing, Thanks for pointing out the Rx cksum test case. I was looking for usage of IXGBE_RXDADV_ERR_SHIFT and IXGBE_RXDADV_ERR_MASK without any result, therefore I assumed these 2 fields are not checked. So it turns out that the implementation of Rx cksum is in routine rx_desc_error_to_pkt_flags of ixgbe_rxtx.c. (Correct me if I'm wrong). This routine, however, doesn't comply with the datasheet. See end of page 324 of 82599 datasheet: >>L4E (10) =97 L4 integrity error is valid only when the L4I bit in the Sta= tus field is set. It is >>active if L4 processing fails (TCP checksum or UDP checksum or SCTP CRC). Also beginning of section 7.1.11 confirms that the error bits are valid when status bits (IPCS/L4CS) are turned on. To be compliant with datasheet, the driver must check respective status bits before checking error bits in receive descriptor. thx & rgds, -Qinglai On Tue, Oct 8, 2013 at 9:59 AM, Zhu, Heqing wrote: > Hi Qinglai, > >>> Besides, as you mentioned, the ixgbe driver doesn't leverage the hardwa= re receive checksum offloading at all. > > On the Rx side, ixgbe driver support the Rx checksum validation via hardw= are offload. There is a simple example @ DPDK\app\test-pmd\csumonly.c to ch= eck IPv4/L4 checksum error~ > > /* Update the L3/L4 checksum error packet count */ > rx_bad_ip_csum +=3D (uint16_t) ((pkt_ol_flags & PKT_RX_IP= _CKSUM_BAD) !=3D 0); > rx_bad_l4_csum +=3D (uint16_t) ((pkt_ol_flags & PKT_RX_L4= _CKSUM_BAD) !=3D 0); > > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of jigsaw > Sent: Saturday, October 05, 2013 3:11 AM > To: Venkatesan, Venky > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH] Request for comments on ixgbe TSO support > > Hi Stephen, > > Thanks for showing a bigger picture. > > GSO is quite big implementation, that I think it won't be easily ported t= o DPDK. The mbuf needs to be equipped with many fields from skb to be able = to deal with GSO. > Do you have the plan to port GSO to DPDK, or you would like to keep GSO i= n scope of virtio? > > Regarding checksum flags, actually I was also thinking of extending ol_fl= ags but then I gave it up coz I was worried about the size of mbuf. > My current patch has to push some work to user, due to the fact that mbuf= delivers too few info (such as L2 and L3 protocol details). > > Besides, as you mentioned, the ixgbe driver doesn't leverage the hardware= receive checksum offloading at all. And if this is to be supported, the ch= ecksum flag need further extension. > (On the other hand, TSO doesn't care about receive checksum offloading). > Again, do you have plans to extend cksum flags so that virio feels more c= omfortable with DPDK? > > Hi Venky, > > I can either make the commit now as is, or wait till the cksum flags exte= nsion is in place. If Stephen (or somebody else) has the plan for better su= pport for cksum offloading or GSO, it is perhaps better to implement TSO on= top of that. > > BTW, I have another small question. Current TSO patch offloads the TCP/IP= pseudo cksum work to user. Do you think DPDK could provide some utility fu= nctions for TCP/IPv4/IPv6 pseudo cksum calculation and updating? > > thx & > rgds, > -Qinglai > > > On Fri, Oct 4, 2013 at 9:38 PM, Venkatesan, Venky wrote: >> Stephen, >> >> Agree on the checksum flag definition. I'm presuming that we should do t= his on the L3 and L4 checksums separately (that ol_flags field is another o= ne that needs extension in the mbuf). >> >> Regards, >> -Venky >> >> >> -----Original Message----- >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Stephen Hemminger >> Sent: Friday, October 04, 2013 11:23 AM >> To: jigsaw >> Cc: dev@dpdk.org >> Subject: Re: [dpdk-dev] [PATCH] Request for comments on ixgbe TSO >> support >> >> On Fri, 4 Oct 2013 20:54:31 +0300 >> jigsaw wrote: >> >>> Hi Stephen, >>> >>> >>> >>This will work for local generated packets but overlapping existing f= ield won't work well for forwarding. >>> So adding a new mss field in mbuf could be the way out? or I >>> misunderstand something. >>> >>> >> What we want to be able to do is to take offload (jumbo) packets >>> >> in with from virtio >>> Sorry I don't understand why TSO is connected to virtio. Could you >>> give more details here? >>> Are you suggesting this TSO patch overlaps your work, or it should be >>> based on your work? >> >> I am working on a better virtio driver. Already have lots more features = working, and doing better offload support is planned. >> >> TSO is a subset of the more generic segment offload (GSO) on Linux. >> With virtio is possible to receive GSO packets as well as send them. >> This feature is negotiated between guest and host. >> >> The idea is that between guests they can exchange jumbo (64K) packets ev= en with a smaller MTU. This helps in many ways. One example is only a singl= e route lookup is needed. >> >> Another issue is that the current DPDK model of offload flags for checks= um is problematic. >> It matches what is available in Intel hardware and is not easily general= izable to other devices. >> >> Current DPDK flag is checksum bad. I would like to change it to >> checksum known good. Then drivers which dont' do checksum would leave >> it 0, but if receive checksum is known good set it to 1. Basically 1 >> means known good, and >> 0 means unknown (or bad). Higher level software can then do sw checksum= if necessary.