From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id F09AD5901 for ; Wed, 12 Nov 2014 10:47:59 +0100 (CET) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 12 Nov 2014 01:57:52 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,367,1413270000"; d="scan'208";a="630679079" Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by fmsmga002.fm.intel.com with ESMTP; 12 Nov 2014 01:57:22 -0800 Received: from irsmsx109.ger.corp.intel.com (163.33.3.23) by IRSMSX101.ger.corp.intel.com (163.33.3.153) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 12 Nov 2014 09:55:45 +0000 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.56]) by IRSMSX109.ger.corp.intel.com ([169.254.13.101]) with mapi id 14.03.0195.001; Wed, 12 Nov 2014 09:55:44 +0000 From: "Ananyev, Konstantin" To: Olivier MATZ , Yong Wang , "Liu, Jijiang" Thread-Topic: [dpdk-dev] [PATCH v8 10/10] app/testpmd:test VxLAN Tx checksum offload Thread-Index: AQHP+igwSkdCwquBBkeqJNewvNm7F5xVaLcAgARPPrCAAFHjgIACB2Ew Date: Wed, 12 Nov 2014 09:55:44 +0000 Message-ID: <2601191342CEEE43887BDE71AB977258213A3F5F@IRSMSX105.ger.corp.intel.com> References: <1414376006-31402-1-git-send-email-jijiang.liu@intel.com> <1414376006-31402-11-git-send-email-jijiang.liu@intel.com> <54588BF7.309@6wind.com> <1ED644BD7E0A5F4091CF203DAFB8E4CC01D8510E@SHSMSX101.ccr.corp.intel.com>, <5459FBB2.1040408@6wind.com> <0c654d2c0d304b45a40af6ca38b70adf@EX13-MBX-026.vmware.com> <545CFE56.60605@6wind.com> <2601191342CEEE43887BDE71AB977258213A38D2@IRSMSX105.ger.corp.intel.com> <5460E07F.6060303@6wind.com> In-Reply-To: <5460E07F.6060303@6wind.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.182] 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 v8 10/10] app/testpmd:test VxLAN Tx 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, 12 Nov 2014 09:48:00 -0000 Hi Oliver, > From: Olivier MATZ [mailto:olivier.matz@6wind.com] > Sent: Monday, November 10, 2014 3:58 PM > To: Ananyev, Konstantin; Yong Wang; Liu, Jijiang > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH v8 10/10] app/testpmd:test VxLAN Tx checks= um offload >=20 > Hello Konstantin, >=20 > >> By the way, we had the same kind of discussion with Konstantin [1] > >> about what to do with the TCP checksum. My feeling is that setting it > >> to the pseudo-header checksum is the best we can do: > >> - linux does that > >> - many hardware requires that (this is not the case for ixgbe, which > >> need a pshdr checksum without the IP len) > >> - it can be reused if received by a virtual device and sent to a > >> physical device supporting TSO > > > > Yes, I remember that discussion. > > I still think we better avoid any read/write access of the packet data = inside PMD TX routine. > > (packet header parsing and/or pseudo-header checksum calculations). > > As I said before - if different HW have different requirements of what = have to be recalculated for HW TX offloads - > > why not introduce a new function dev_prep_tx(portid, queueid, mbuf[], n= um)? > > PMD developer can put all necessary calculations/updates of the packet = data and related mbuf fields inside that function. > > It would be then a PMD responsibility to provide that function and it w= ould be an app layer responsibility to call it for > > mbufs with TX offload flags before calling tx_burst(). >=20 > I think I understand your point: you don't want to touch the packet > in the PMD because the lcore that transmits the packet can be different > than the one that built it. In this case (i.e. a pipeline case), > reading or writing the packet can produce a cache miss, is it correct? Yes, it is correct.=20 That's one of the main reason why current implementations of TX routines av= oid touching packet data.=20 > From an API perspective, it looks a bit more complex to have to call > dev_prep_tx() before sending the packets if they have been flagged > for offload processing. But I admit I have no other argument. I'll be > happy to have more comments from other people on the list. >=20 > I'm sending a first version of the patchset now as it's ready, it does > not take in account this comment, but I'm open to add it in a v2 if > there is a consensus on this. >=20 > Now, knowing that: > - adding dev_prep_tx() will also concern hw checksum (TCP L4 checksum > already requires to set the TCP pseudo header checksum), so adding > this will change the API of an existing feature > - TSO is a new feature expected for 1.8 (which should be out soon) >=20 > Do you think we need to include this for 1.8 or can we postpone your > proposition for after the 1.8 release? I'd say it would be good to have it done together with TSO feature. About changing API: I think existing applications shouldn't be affected. For existing PMDs/TX offloads we don't change any rules what need to be fi= lled by the app. We just add a new function that can do that for user. If the app fills required manually (as all apps have to do now) it would ke= ep working as expected.=20 If you feel like it is too much work for 1.8 timeframe - can we at least move fix_tcp_phdr_cksum() out of TX PMD as a temporary meas= ure? Let say create a function get_ipv4_udptcp_checksum(struct rte_mbuf *m) (in= librte_net ?). It will calculate PSD checksum for both TSO and non-TSO case based on given= mbuf flags/fields. Then we can update testpmd/csumonly.c to use it. Thanks Konstantin =20 > Thank you for your comments, > Regards, > Olivier >=20 >=20 >=20 > >> [1] http://dpdk.org/ml/archives/dev/2014-May/002766.html