From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
Subject: Re: [PATCH 2/5] gso/lib: add TCP/IPv4 GSO support
Date: Wed, 30 Aug 2017 09:39:09 +0000
Message-ID: <2601191342CEEE43887BDE71AB9772584F23E197@IRSMSX103.ger.corp.intel.com>
References: <1503584144-63181-1-git-send-email-jiayu.hu@intel.com>
 <1503584144-63181-3-git-send-email-jiayu.hu@intel.com>
 <2601191342CEEE43887BDE71AB9772584F23E097@IRSMSX103.ger.corp.intel.com>
 <20170830025550.GA113170@dpdk15.sh.intel.com>
 <DC5AD7FA266D86499789B1BCAEC715F8C31A75A8@IRSMSX101.ger.corp.intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Cc: "dev@dpdk.org" <dev@dpdk.org>, "Tan, Jianfeng" <jianfeng.tan@intel.com>
To: "Kavanagh, Mark B" <mark.b.kavanagh@intel.com>, "Hu, Jiayu"
 <jiayu.hu@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mga01.intel.com (mga01.intel.com [192.55.52.88])
 by dpdk.org (Postfix) with ESMTP id B0D8B2C02
 for <dev@dpdk.org>; Wed, 30 Aug 2017 11:39:12 +0200 (CEST)
In-Reply-To: <DC5AD7FA266D86499789B1BCAEC715F8C31A75A8@IRSMSX101.ger.corp.intel.com>
Content-Language: en-US
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

Hi Mark,

> >> > +
> >> > +void
> >> > +gso_parse_packet(struct rte_mbuf *pkt)
> >>
> >> There is a function rte_net_get_ptype() that supposed to provide simil=
ar
> >functionality.
> >> So we probably don't need to create a new SW parse function here, inst=
ead
> >would be better
> >> to reuse (and update if needed) an existing one.
> >> Again user already might have l2/l3/l4.../_len and packet_type setuped=
.
> >> So better to keep SW packet parsing out of scope of that library.
> >
> >Hmm, I know we have discussed this design choice in the GRO library, and=
 I
> >also think it's
> >better to reuse these values.
> >
> >But from the perspective of OVS, it may add extra overhead, since OVS do=
esn't
> >parse every
> >packet originally. Maybe @Mark can give us more inputs from the view of =
OVS.
>=20
> Hi Jiayu, Konstantin
>=20
> For GSO, the application needs to know:
> - the packet type (as it only currently supports TCP/IPv4, VxLAN, GRE pac=
kets)
> - the l2/3/4_lens, etc. (in order to replicate the original packet's head=
ers across outgoing segments)
>=20
> For this, we can use the rte_net_get_ptype function, as per Konstantin's =
suggestion, as it provides both - thanks Konstantin!
>=20
> WRT the extra overhead in OvS: TSO is the defacto standard, and GSO is pr=
ovided purely as a fallback option. As such, and since the
> additional packet parsing is a necessity in order to facilitate GSO, the =
additional overhead is IMO acceptable.

As I remember, for TSO in DPDK user still have to provide l2/l3/l4_len and =
mss information to the PMD.
So unless user knows these value straightway (user creates a packet himself=
) some packet processing will be unavailable anyway.
Konstantin
>=20
> Thanks,
> Mark
>=20