From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: Ophir Munk <ophirmu@mellanox.com>,
"Hu, Jiayu" <jiayu.hu@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
Cc: Thomas Monjalon <thomas@monjalon.net>,
Olga Shern <olgas@mellanox.com>,
Pascal Mazon <pascal.mazon@6wind.com>,
"stable@dpdk.org" <stable@dpdk.org>
Subject: Re: [dpdk-stable] [PATCH v1] gso: fix marking TCP checksum flag in TCP segments
Date: Tue, 24 Apr 2018 10:56:09 +0000 [thread overview]
Message-ID: <2601191342CEEE43887BDE71AB977258AEA5081C@IRSMSX102.ger.corp.intel.com> (raw)
In-Reply-To: <HE1PR0501MB23140AD5F8652DA56AD1F8BAD1880@HE1PR0501MB2314.eurprd05.prod.outlook.com>
> -----Original Message-----
> From: Ophir Munk [mailto:ophirmu@mellanox.com]
> Sent: Tuesday, April 24, 2018 10:44 AM
> To: Hu, Jiayu <jiayu.hu@intel.com>; dev@dpdk.org; Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Cc: Thomas Monjalon <thomas@monjalon.net>; Olga Shern <olgas@mellanox.com>; Pascal Mazon <pascal.mazon@6wind.com>;
> stable@dpdk.org
> Subject: RE: [PATCH v1] gso: fix marking TCP checksum flag in TCP segments
>
> Hi Jiayu,
> Please find comments inline
>
> > -----Original Message-----
> > From: Hu, Jiayu [mailto:jiayu.hu@intel.com]
> > Sent: Monday, April 23, 2018 7:14 AM
> > To: Ophir Munk <ophirmu@mellanox.com>; dev@dpdk.org; Ananyev,
> > Konstantin <konstantin.ananyev@intel.com>
> > Cc: Thomas Monjalon <thomas@monjalon.net>; Olga Shern
> > <olgas@mellanox.com>; Pascal Mazon <pascal.mazon@6wind.com>;
> > stable@dpdk.org
> > Subject: RE: [PATCH v1] gso: fix marking TCP checksum flag in TCP segments
> >
> > Hi Ophir,
> >
> > In the GSO design, the GSO library doesn't care about checksums, which
> > means it doesn't check if input packets have correct checksums, and it
> > doesn't do any checksum related work for the output GSO segments. It
> > depends on the callers to use HW or SW checksum calculation for output
> > packets. This is why the GSO library doesn't set PKT_TX_TCP_CKSUM. So I
> > don't think it's a bug.
> >
>
> Can you please reconsider this design? I think the GSO library should imitate the HW behavior where TCP segments checksum is
> automatically calculated without explicitly requesting it. I am not saying that GSO library itself should calculate the checksums - but at least
> it should mark each segment as requiring this calculation.
But gso has no idea how this packet will be processed after it.
Caller can choose to calculate L3/L4 cksum in SW or might be going to use HW offloads.
In later case nothing stops the caller to update mbuf->ol_flags in a way he likes (TCP_CKSUM, IP_CKSUM, etc.).
Konstantin
>
> > In my opinion, it's not a good idea to enable HW TCP checksum calculation
> > silently, and without the aware of the caller. In fact, the caller always know it
> > does SW TSO (i.e. GSO), instead of real HW TSO.
>
> This is not correct. Consider net_failsafe with 2 sub-devices: one is a HW PCI device, the other one is a SW TAP device. Failsafe must work
> transparently with these two sub-devices and the caller cannot tell if TSO is done in SW or HW.
>
> > If the caller wants HW
> > checksum calculation, it can add PKT_TX_TCP_CKSUM to ol_flags before or
> > after calling the GSO library.
> >
>
> FYI - TAP TSO patches were submitted to dpdk.org mailing list. These patches use the GSO library.
> https://dpdk.org/dev/patchwork/patch/38666/
> https://dpdk.org/dev/patchwork/patch/38667/
>
> Running testpmd with TAP TSO is currently broken without the suggested librte_gso patch.
> Please note testpmd implementation (app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c) in case *both* TSO and TCP CKSUM are
> configured:
>
> if (tso_segsz)
> ol_flags |= PKT_TX_TCP_SEG; // *** if TSO is applicable - the packet flags are only marked with PKT_TX_TCP_SEG and no
> PKT_TX_TCP_CKSUM ***
> else if (tx_offloads & DEV_TX_OFFLOAD_TCP_CKSUM)
> ol_flags |= PKT_TX_TCP_CKSUM; // *** PKT_TX_TCP_CKSUM is marked only if TSO is not applicable ***
> else {
> tcp_hdr->cksum =
> get_udptcp_checksum(l3_hdr, tcp_hdr,
>
> In other words - testpmd does not set TCP_CKSUM along with TCP_SEG therefore using testpmd with TAP/TSO will result in TCP segments
> with 0 (incorrect) TCP checksums.
>
> In addition - please note the comments in lib/librte_mbuf/rte_mbuf.h which specify that PKT_TX_TCP_SEG flag implies the
> PKT_TX_TCP_CKSUM (hence it is not required to be explicitly set by the caller)
>
> /**
> * TCP segmentation offload. To enable this offload feature for a
> * packet to be transmitted on hardware supporting TSO:
> * - set the PKT_TX_TCP_SEG flag in mbuf->ol_flags (this flag implies
> * PKT_TX_TCP_CKSUM)
> ...
>
> > Add Konstantin for more suggestions.
> >
> > Thanks,
> > Jiayu
> >
> > > -----Original Message-----
> > > From: Ophir Munk [mailto:ophirmu@mellanox.com]
> > > Sent: Sunday, April 22, 2018 10:21 PM
> > > To: dev@dpdk.org; Hu, Jiayu <jiayu.hu@intel.com>
> > > Cc: Thomas Monjalon <thomas@monjalon.net>; Olga Shern
> > > <olgas@mellanox.com>; Pascal Mazon <pascal.mazon@6wind.com>;
> > Ophir
> > > Munk <ophirmu@mellanox.com>; stable@dpdk.org
> > > Subject: [PATCH v1] gso: fix marking TCP checksum flag in TCP segments
> > >
> > > Large TCP packets which are marked with PKT_TX_TCP_SEG flag are
> > > segmented and the flag is cleared in the resulting segments, however,
> > > the segments checksum is not updated. It is therefore required to set
> > > the PKT_TX_TCP_CKSUM flag in each TCP segment in order to mark for the
> > > sending driver the need to update the TCP checksum before transmitting
> > > the segment.
> > >
> > > Fixes: 119583797b6a ("gso: support TCP/IPv4 GSO")
> > > Cc: stable@dpdk.org
> > >
> > > Signed-off-by: Ophir Munk <ophirmu@mellanox.com>
> > > ---
> > > lib/librte_gso/rte_gso.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/lib/librte_gso/rte_gso.c b/lib/librte_gso/rte_gso.c index
> > > a44e3d4..e9ce9ce 100644
> > > --- a/lib/librte_gso/rte_gso.c
> > > +++ b/lib/librte_gso/rte_gso.c
> > > @@ -50,12 +50,14 @@ rte_gso_segment(struct rte_mbuf *pkt,
> > > ((IS_IPV4_GRE_TCP4(pkt->ol_flags) &&
> > > (gso_ctx->gso_types &
> > > DEV_TX_OFFLOAD_GRE_TNL_TSO)))) {
> > > pkt->ol_flags &= (~PKT_TX_TCP_SEG);
> > > + pkt->ol_flags |= PKT_TX_TCP_CKSUM;
> > > ret = gso_tunnel_tcp4_segment(pkt, gso_size, ipid_delta,
> > > direct_pool, indirect_pool,
> > > pkts_out, nb_pkts_out);
> > > } else if (IS_IPV4_TCP(pkt->ol_flags) &&
> > > (gso_ctx->gso_types &
> > > DEV_TX_OFFLOAD_TCP_TSO)) {
> > > pkt->ol_flags &= (~PKT_TX_TCP_SEG);
> > > + pkt->ol_flags |= PKT_TX_TCP_CKSUM;
> > > ret = gso_tcp4_segment(pkt, gso_size, ipid_delta,
> > > direct_pool, indirect_pool,
> > > pkts_out, nb_pkts_out);
> > > --
> > > 2.7.4
next prev parent reply other threads:[~2018-04-24 10:56 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-22 14:20 Ophir Munk
2018-04-22 14:47 ` Ophir Munk
2018-04-23 4:13 ` Hu, Jiayu
2018-04-24 9:44 ` Ophir Munk
2018-04-24 10:56 ` Ananyev, Konstantin [this message]
2018-04-24 11:45 ` Ophir Munk
2018-04-24 12:31 ` Ananyev, Konstantin
2018-04-24 12:55 ` Hu, Jiayu
2018-04-24 13:53 ` Ophir Munk
2018-04-25 1:51 ` Hu, Jiayu
2018-04-24 13:41 ` Ophir Munk
2018-04-24 14:26 ` Ananyev, Konstantin
-- strict thread matches above, loose matches on Subject: below --
2018-04-22 14:19 Ophir Munk
2018-04-30 13:38 ` Luca Boccassi
2018-04-22 14:15 Ophir Munk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2601191342CEEE43887BDE71AB977258AEA5081C@IRSMSX102.ger.corp.intel.com \
--to=konstantin.ananyev@intel.com \
--cc=dev@dpdk.org \
--cc=jiayu.hu@intel.com \
--cc=olgas@mellanox.com \
--cc=ophirmu@mellanox.com \
--cc=pascal.mazon@6wind.com \
--cc=stable@dpdk.org \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).