From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by dpdk.org (Postfix) with ESMTP id DD2FB1F3 for ; Tue, 8 Oct 2013 08:58:44 +0200 (CEST) Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga101.ch.intel.com with ESMTP; 07 Oct 2013 23:59:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.90,1055,1371106800"; d="scan'208";a="304581169" Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228]) by AZSMGA002.ch.intel.com with ESMTP; 07 Oct 2013 23:59:22 -0700 Received: from FMSMSX110.amr.corp.intel.com (10.18.116.10) by FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 7 Oct 2013 23:59:22 -0700 Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by fmsmsx110.amr.corp.intel.com (10.18.116.10) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 7 Oct 2013 23:59:18 -0700 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.4]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.80]) with mapi id 14.03.0123.003; Tue, 8 Oct 2013 14:59:10 +0800 From: "Zhu, Heqing" To: jigsaw , "Venkatesan, Venky" Thread-Topic: [dpdk-dev] [PATCH] Request for comments on ixgbe TSO support Thread-Index: AQHOwSRBQx4BKtZW6USrWueF/bQ9uZnkST4AgAAD64CAAAf3AIAABGmAgAAI3oCABgEGoA== Date: Tue, 8 Oct 2013 06:59:10 +0000 Message-ID: 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> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 06:58:46 -0000 Hi Qinglai,=20 >> Besides, as you mentioned, the ixgbe driver doesn't leverage the hardwar= e receive checksum offloading at all. On the Rx side, ixgbe driver support the Rx checksum validation via hardwar= e offload. There is a simple example @ DPDK\app\test-pmd\csumonly.c to chec= k IPv4/L4 checksum error~=20 /* 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 to = 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 in = scope of virtio? Regarding checksum flags, actually I was also thinking of extending ol_flag= s 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 d= elivers too few info (such as L2 and L3 protocol details). Besides, as you mentioned, the ixgbe driver doesn't leverage the hardware r= eceive checksum offloading at all. And if this is to be supported, the chec= ksum 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 com= fortable with DPDK? Hi Venky, I can either make the commit now as is, or wait till the cksum flags extens= ion is in place. If Stephen (or somebody else) has the plan for better supp= ort for cksum offloading or GSO, it is perhaps better to implement TSO on t= op of that. BTW, I have another small question. Current TSO patch offloads the TCP/IP p= seudo cksum work to user. Do you think DPDK could provide some utility func= tions 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 th= is on the L3 and L4 checksums separately (that ol_flags field is another on= e 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=20 > support > > On Fri, 4 Oct 2013 20:54:31 +0300 > jigsaw wrote: > >> Hi Stephen, >> >> >> >>This will work for local generated packets but overlapping existing fi= eld won't work well for forwarding. >> So adding a new mss field in mbuf could be the way out? or I=20 >> misunderstand something. >> >> >> What we want to be able to do is to take offload (jumbo) packets=20 >> >> in with from virtio >> Sorry I don't understand why TSO is connected to virtio. Could you=20 >> give more details here? >> Are you suggesting this TSO patch overlaps your work, or it should be=20 >> based on your work? > > I am working on a better virtio driver. Already have lots more features w= orking, 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 eve= n with a smaller MTU. This helps in many ways. One example is only a single= route lookup is needed. > > Another issue is that the current DPDK model of offload flags for checksu= m is problematic. > It matches what is available in Intel hardware and is not easily generali= zable to other devices. > > Current DPDK flag is checksum bad. I would like to change it to=20 > checksum known good. Then drivers which dont' do checksum would leave=20 > it 0, but if receive checksum is known good set it to 1. Basically 1=20 > means known good, and > 0 means unknown (or bad). Higher level software can then do sw checksum = if necessary.