From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua0-f180.google.com (mail-ua0-f180.google.com [209.85.217.180]) by dpdk.org (Postfix) with ESMTP id 653DC2A66 for ; Wed, 7 Dec 2016 15:31:02 +0100 (CET) Received: by mail-ua0-f180.google.com with SMTP id 12so416828014uas.2 for ; Wed, 07 Dec 2016 06:31:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DM7KfV9ZP+qi0YF+arhB3czTvBkFFK4txbH1786nfwM=; b=ulrzc9Mg/psyj8V0hveYSh2gvra2kvovYiBZEpX4z1YFANeLV4z3OlY1//kjiOU7vV 7X9uNA7MpJ9dW5UCGgts+ExEEseFWKveYVuYNBNti28AxEemlYHsWcRH3Dt8LJZg/coM M1iTec16y9zoitDBZKArEyVvduFrxP33CX5LLEwTfXCjXoDrQWGXwzwy1mjkuQIyR7JI EC/pXVlCCfaBZo7K8/R8hIneYZD2UevZuRi7pcFazwY91wU/w7G2TMZ8GgJprWakiD4X UaGDpvK4xBmlKwESnbk1B6yi+5uuni1tEgmIQtfu4SJ8bUUoR5JMYGfvMDKauXSLqIkr ztWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DM7KfV9ZP+qi0YF+arhB3czTvBkFFK4txbH1786nfwM=; b=QDavksIRholj3Im1XhHD03j1BG8kqnMKSG2wgt3EIwtz+HEi3AbbMG7juW1lnIwtM1 yYMDlSDX8LiSDNekYfQ8lHXE6LR/0Xk9udmd1AxhuLazZYM+7mGCyyaxKXj3TXaA4iwq 5oNtZvrEHqA3ZrvgoBMVq+wi1uZWCdLj+N64cpecjArv46zBQUCNGyKS5sJG+yScFLEr GF+SHNPv/tCoB/qLG4ahr3lxFdgQZ5zcBU4QCDqkreg0jcnKP+bJj68GLgoIIcbCjvxQ CJ4yk/hwcqXYNsYihO/7cDNbJ5VSyu8/CbOSR+5BqMB946u1k+TEwp/JKh3PgqjqRpN9 Hwow== X-Gm-Message-State: AKaTC0305h6XG2zo1TYOhUTALd1Tf+w6NRRllP3ivA+np+xBlqjZa6xQc65ARnr/4JX4Tpg3OZ6NGQ6uhLndoztj X-Received: by 10.176.81.56 with SMTP id e53mr55206769uaa.100.1481121061648; Wed, 07 Dec 2016 06:31:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.46.3 with HTTP; Wed, 7 Dec 2016 06:31:00 -0800 (PST) In-Reply-To: <2601191342CEEE43887BDE71AB9772583F0E4E05@irsmsx105.ger.corp.intel.com> References: <1477486575-25148-1-git-send-email-tomaszx.kulasek@intel.com> <2601191342CEEE43887BDE71AB9772583F0E2444@irsmsx105.ger.corp.intel.com> <3517413.XL3bTbAyaC@xps13> <2601191342CEEE43887BDE71AB9772583F0E3B03@irsmsx105.ger.corp.intel.com> <8b0acf96-cba9-6c91-92c4-93674052e995@intel.com> <2601191342CEEE43887BDE71AB9772583F0E4E05@irsmsx105.ger.corp.intel.com> From: Alejandro Lucero Date: Wed, 7 Dec 2016 14:31:00 +0000 Message-ID: To: "Ananyev, Konstantin" Cc: "Yigit, Ferruh" , Yong Wang , Thomas Monjalon , Harish Patil , "dev@dpdk.org" , Rahul Lakkireddy , Stephen Hurd , Jan Medala , Jakub Palider , John Daley , Adrien Mazarguil , Rasesh Mody , "Jacob, Jerin" , Yuanhan Liu , "Kulasek, TomaszX" , "olivier.matz@6wind.com" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v12 0/6] add Tx preparation X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 14:31:02 -0000 For NFP, we do not have TSO support yet, although it is coming and hopefully it will be within next release. Regarding this email thread, it is "it is OK, we do not need any checksum preparation for TSO" On Wed, Dec 7, 2016 at 10:03 AM, Ananyev, Konstantin < konstantin.ananyev@intel.com> wrote: > > Hi Ferruh, > > > > > On 12/6/2016 6:25 PM, Yong Wang wrote: > > >> -----Original Message----- > > >> From: Ananyev, Konstantin [mailto:konstantin.ananyev@intel.com] > > >> Sent: Sunday, December 4, 2016 4:11 AM > > >> To: Yong Wang ; Thomas Monjalon > > >> > > >> Cc: Harish Patil ; dev@dpdk.org; Rahul > Lakkireddy > > >> ; Stephen Hurd > > >> ; Jan Medala ; Jakub > > >> Palider ; John Daley ; Adrien > > >> Mazarguil ; Alejandro Lucero > > >> ; Rasesh Mody > > >> ; Jacob, Jerin ; > > >> Yuanhan Liu ; Kulasek, TomaszX > > >> ; olivier.matz@6wind.com > > >> Subject: RE: [dpdk-dev] [PATCH v12 0/6] add Tx preparation > > >> > > >> Hi > > >> > > >> > > >> > > >>>> > > >> > > >>>> 2016-11-30 17:42, Ananyev, Konstantin: > > >> > > >>>>>>> Please, we need a comment for each driver saying > > >> > > >>>>>>> "it is OK, we do not need any checksum preparation for TSO" > > >> > > >>>>>>> or > > >> > > >>>>>>> "yes we have to implement tx_prepare or TSO will not work in th= is > > >> > > >>>> mode" > > >> > > >>>>>>> > > >> > > >>>>>> > > >> > > >>>>>> qede PMD doesn=E2=80=99t currently support TSO yet, it only supp= orts Tx > > >> > > >>>> TCP/UDP/IP > > >> > > >>>>>> csum offloads. > > >> > > >>>>>> So Tx preparation isn=E2=80=99t applicable. So as of now - > > >> > > >>>>>> "it is OK, we do not need any checksum preparation for TSO" > > >> > > >>>>> > > >> > > >>>>> Thanks for the answer. > > >> > > >>>>> Though please note that it not only for TSO. > > >> > > >>>> > > >> > > >>>> Oh yes, sorry, my wording was incorrect. > > >> > > >>>> We need to know if any checksum preparation is needed prior > > >> > > >>>> offloading its final computation to the hardware or driver. > > >> > > >>>> So the question applies to TSO and simple checksum offload. > > >> > > >>>> > > >> > > >>>> We are still waiting answers for > > >> > > >>>> bnxt, cxgbe, ena, nfp, thunderx, virtio and vmxnet3. > > >> > > >>> > > >> > > >>> The case for a virtual device is a little bit more complicated as > packets > > >> offloaded from a virtual device can eventually be delivered to > > >> > > >>> another virtual NIC or different physical NICs that have different > offload > > >> requirements. In ESX, the hypervisor will enforce that the packets > > >> > > >>> offloaded will be something that the hardware expects. The contrac= t > for > > >> vmxnet3 is that the guest needs to fill in pseudo header checksum > > >> > > >>> for both l4 checksum only and TSO + l4 checksum offload cases. > > >> > > >> > > >> > > >> Ok, so at first glance that looks to me very similar to Intel HW > requirements. > > >> > > >> Could you confirm would rte_net_intel_cksum_prepare() > > >> > > >> also work for vmxnet3 or some extra modifications are required? > > >> > > >> You can look at it here: https://urldefense.proofpoint. > com/v2/url?u=3Dhttp- > > >> 3A__dpdk.org_dev_patchwork_patch_17184_&d=3DDgIGaQ&c=3DuilaK90D4TOV > > >> oH58JNXRgQ&r=3Dv4BBYIqiDq552fkYnKKFBFyqvMXOR3UXSdFO2plFD1s&m=3DNS > > >> 4zOl2je_tyGhnOJMSnu37HmJxOZf-1KLYcVsu8iYY&s=3DdL-NOC- > > >> 18HclXUURQzuyW5Udw4NY13pKMndYvfgCfbA&e=3D . > > >> > > >> Note that for Intel HW the rules for pseudo-header csum calculation > > >> > > >> differ for TSO and non-TSO case. > > >> > > >> For TSO length inside pseudo-header are set to 0, while for non-tso > case > > >> > > >> It should be set to L3 payload length. > > >> > > >> Is it the same for vmxnet3 or no? > > >> > > >> Thanks > > >> > > >> Konstantin > > >> > > > > > > Yes and this is the same for vmxnet3. > > > > > > > This means vmxnet3 PMD also should be updated, right? > > Yes, that's right. > > >Should that update > > be part of tx_prep patchset? Or separate patch? > > Another question I suppose is who will do the actual patch for vmxnet3. > Yong, are you ok to do the patch for vmxnet3, or prefer us to do that? > Please note, that in both cases will need your help in testing/reviewing > it. > Konstantin > > > > > >>> > > >> > > >>>>> This is for any TX offload for which the upper layer SW would hav= e > > >> > > >>>>> to modify the contents of the packet. > > >> > > >>>>> Though as I can see for qede neither PKT_TX_IP_CKSUM or > > >> > > >>>> PKT_TX_TCP_CKSUM > > >> > > >>>>> exhibits any extra requirements for the user. > > >> > > >>>>> Is that correct? > > >> > > >> > > > > >