From: Ophir Munk <ophirmu@mellanox.com>
To: "Hu, Jiayu" <jiayu.hu@intel.com>, "dev@dpdk.org" <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" <stable@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v1] gso: fix marking TCP checksum flag in TCP segments
Date: Tue, 24 Apr 2018 09:44:18 +0000 [thread overview]
Message-ID: <HE1PR0501MB23140AD5F8652DA56AD1F8BAD1880@HE1PR0501MB2314.eurprd05.prod.outlook.com> (raw)
In-Reply-To: <ED946F0BEFE0A141B63BABBD629A2A9B388B3D55@shsmsx102.ccr.corp.intel.com>
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.
> 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 9:44 UTC|newest]
Thread overview: 12+ 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 [this message]
2018-04-24 10:56 ` Ananyev, Konstantin
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
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=HE1PR0501MB23140AD5F8652DA56AD1F8BAD1880@HE1PR0501MB2314.eurprd05.prod.outlook.com \
--to=ophirmu@mellanox.com \
--cc=dev@dpdk.org \
--cc=jiayu.hu@intel.com \
--cc=konstantin.ananyev@intel.com \
--cc=olgas@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).