From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 0C76E691A for ; Fri, 4 Oct 2013 20:38:08 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 04 Oct 2013 11:38:51 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.90,1034,1371106800"; d="scan'208";a="414139339" Received: from orsmsx102.amr.corp.intel.com ([10.22.225.129]) by orsmga002.jf.intel.com with ESMTP; 04 Oct 2013 11:38:50 -0700 Received: from orsmsx159.amr.corp.intel.com (10.22.240.24) by ORSMSX102.amr.corp.intel.com (10.22.225.129) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 4 Oct 2013 11:38:50 -0700 Received: from orsmsx102.amr.corp.intel.com ([169.254.1.143]) by ORSMSX159.amr.corp.intel.com ([169.254.11.187]) with mapi id 14.03.0123.003; Fri, 4 Oct 2013 11:38:50 -0700 From: "Venkatesan, Venky" To: Stephen Hemminger , jigsaw Thread-Topic: [dpdk-dev] [PATCH] Request for comments on ixgbe TSO support Thread-Index: AQHOwS7mZzM76/OrWkqJDsAjqIJaLpnk3pcw Date: Fri, 4 Oct 2013 18:38:49 +0000 Message-ID: <1FD9B82B8BF2CF418D9A1000154491D973F58EE2@ORSMSX102.amr.corp.intel.com> References: <1380906413-3406-1-git-send-email-jigsaw@gmail.com> <20131004104030.206356dd@nehalam.linuxnetplumber.net> <20131004112302.50693f04@nehalam.linuxnetplumber.net> In-Reply-To: <20131004112302.50693f04@nehalam.linuxnetplumber.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.140] 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: Fri, 04 Oct 2013 18:38:09 -0000 Stephen,=20 Agree on the checksum flag definition. I'm presuming that we should do this= on the L3 and L4 checksums separately (that ol_flags field is another one = that needs extension in the mbuf).=20 Regards,=20 -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, >=20 >=20 > >>This will work for local generated packets but overlapping existing fie= ld won't work well for forwarding. > So adding a new mss field in mbuf could be the way out? or I=20 > misunderstand something. >=20 > >> What we want to be able to do is to take offload (jumbo) packets in=20 > >> 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 wor= king, 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 even = with a smaller MTU. This helps in many ways. One example is only a single r= oute lookup is needed. Another issue is that the current DPDK model of offload flags for checksum = is problematic. It matches what is available in Intel hardware and is not easily generaliza= ble to other devices. Current DPDK flag is checksum bad. I would like to change it to checksum kn= own good. Then drivers which dont' do checksum would leave it 0, but if rec= eive 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.