From: Olivier Matz <olivier.matz@6wind.com>
To: David Marchand <david.marchand@redhat.com>
Cc: dev@dpdk.org, stable@dpdk.org, Ales Musil <amusil@redhat.com>,
Thomas Monjalon <thomas@monjalon.net>,
Ophir Munk <ophirmu@nvidia.com>,
Keith Wiles <keith.wiles@intel.com>,
Raslan Darawsheh <rasland@mellanox.com>
Subject: Re: [PATCH] net/tap: fix L4 checksum
Date: Tue, 22 Aug 2023 10:55:43 +0200 [thread overview]
Message-ID: <ZOR4DzpdH4KftTWT@platinum> (raw)
In-Reply-To: <20230822073244.3751885-1-david.marchand@redhat.com>
Hi David,
On Tue, Aug 22, 2023 at 09:32:44AM +0200, David Marchand wrote:
> The L4 checksum offloading API does not require l4_len to be set.
> Make the driver discover the L4 headers size by itself.
>
> Fixes: 6546e76056e3 ("net/tap: calculate checksums of multi segs packets")
> Cc: stable@dpdk.org
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
> Tested-by: Ales Musil <amusil@redhat.com>
> ---
> .mailmap | 1 +
> drivers/net/tap/rte_eth_tap.c | 13 +++++++++++--
> 2 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/.mailmap b/.mailmap
> index 864d33ee46..b6a21b35cb 100644
> --- a/.mailmap
> +++ b/.mailmap
> @@ -40,6 +40,7 @@ Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> Aleksandr Miloshenko <a.miloshenko@f5.com>
> Aleksey Baulin <aleksey.baulin@gmail.com>
> Aleksey Katargin <gureedo@gmail.com>
> +Ales Musil <amusil@redhat.com>
> Alexander Bechikov <asb.tyum@gmail.com>
> Alexander Belyakov <abelyako@gmail.com>
> Alexander Chernavin <achernavin@netgate.com>
> diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c
> index bf98f75559..0ab214847a 100644
> --- a/drivers/net/tap/rte_eth_tap.c
> +++ b/drivers/net/tap/rte_eth_tap.c
> @@ -645,13 +645,22 @@ tap_write_mbufs(struct tx_queue *txq, uint16_t num_mbufs,
> ((mbuf->ol_flags & (RTE_MBUF_F_TX_IP_CKSUM | RTE_MBUF_F_TX_IPV4) ||
> (mbuf->ol_flags & RTE_MBUF_F_TX_L4_MASK) == RTE_MBUF_F_TX_UDP_CKSUM ||
> (mbuf->ol_flags & RTE_MBUF_F_TX_L4_MASK) == RTE_MBUF_F_TX_TCP_CKSUM))) {
While looking at the patch, I noticed this line:
mbuf->ol_flags & (RTE_MBUF_F_TX_IP_CKSUM | RTE_MBUF_F_TX_IPV4)
I think only RTE_MBUF_F_TX_IP_CKSUM should be checked.
> + unsigned int l4_len = 0;
> +
> is_cksum = 1;
>
> + if ((mbuf->ol_flags & RTE_MBUF_F_TX_L4_MASK) ==
> + RTE_MBUF_F_TX_UDP_CKSUM)
> + l4_len = sizeof(struct rte_udp_hdr);
> + else if ((mbuf->ol_flags & RTE_MBUF_F_TX_L4_MASK) ==
> + RTE_MBUF_F_TX_TCP_CKSUM)
> + l4_len = sizeof(struct rte_tcp_hdr);
> +
> /* Support only packets with at least layer 4
> * header included in the first segment
> */
> seg_len = rte_pktmbuf_data_len(mbuf);
> - l234_hlen = mbuf->l2_len + mbuf->l3_len + mbuf->l4_len;
> + l234_hlen = mbuf->l2_len + mbuf->l3_len + l4_len;
> if (seg_len < l234_hlen)
> return -1;
>
> @@ -661,7 +670,7 @@ tap_write_mbufs(struct tx_queue *txq, uint16_t num_mbufs,
> rte_memcpy(m_copy, rte_pktmbuf_mtod(mbuf, void *),
> l234_hlen);
> tap_tx_l3_cksum(m_copy, mbuf->ol_flags,
> - mbuf->l2_len, mbuf->l3_len, mbuf->l4_len,
> + mbuf->l2_len, mbuf->l3_len, l4_len,
> &l4_cksum, &l4_phdr_cksum,
> &l4_raw_cksum);
> iovecs[k].iov_base = m_copy;
> --
> 2.41.0
>
Using rte_ipv4_udptcp_cksum() in this code would probably simplify it, and may
solve other issues (for instance the 0 checksum for UDP which has a special
meaning).
next prev parent reply other threads:[~2023-08-22 8:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-22 7:32 [PATCH] net/tap: fix L4 checksum David Marchand
2023-08-22 8:55 ` Olivier Matz [this message]
2023-08-22 15:44 ` David Marchand
2023-08-23 16:01 ` [PATCH v2 1/3] net/tap: fix L4 checksum offloading David Marchand
2023-08-23 16:01 ` [PATCH v2 2/3] net/tap: fix IPv4 " David Marchand
2023-08-23 16:01 ` [PATCH v2 3/3] net/tap: rework " David Marchand
2023-08-24 7:18 ` [PATCH v3 1/3] net/tap: fix L4 " David Marchand
2023-08-24 7:18 ` [PATCH v3 2/3] net/tap: fix IPv4 " David Marchand
2023-08-24 7:18 ` [PATCH v3 3/3] net/tap: rework " David Marchand
2023-11-02 1:21 ` [PATCH v3 1/3] net/tap: fix L4 " Ferruh Yigit
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=ZOR4DzpdH4KftTWT@platinum \
--to=olivier.matz@6wind.com \
--cc=amusil@redhat.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=keith.wiles@intel.com \
--cc=ophirmu@nvidia.com \
--cc=rasland@mellanox.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.