[dpdk-stable] [dpdk-dev] [PATCH v3] net: fix Intel-specific Prepare the outer ipv4 hdr for checksum
Olivier Matz
olivier.matz at 6wind.com
Fri Jul 30 13:11:53 CEST 2021
On Wed, Jul 28, 2021 at 06:46:53PM +0300, Andrew Rybchenko wrote:
> On 7/7/21 12:40 PM, Mohsin Kazmi wrote:
> > Preparation the headers for the hardware offload
> > misses the outer ipv4 checksum offload.
> > It results in bad checksum computed by hardware NIC.
> >
> > This patch fixes the issue by setting the outer ipv4
> > checksum field to 0.
> >
> > Fixes: 4fb7e803eb1a ("ethdev: add Tx preparation")
> > Cc: stable at dpdk.org
> >
> > Signed-off-by: Mohsin Kazmi <mohsin.kazmi14 at gmail.com>
> > Acked-by: Qi Zhang <qi.z.zhang at intel.com>
> > ---
> > v3:
> > * Update the conditional test with PKT_TX_OUTER_IP_CKSUM.
> > * Update the commit title with "Intel-specific".
> >
> > v2:
> > * Update the commit message with Fixes.
> >
> > lib/net/rte_net.h | 15 +++++++++++++--
> > 1 file changed, 13 insertions(+), 2 deletions(-)
> >
> > diff --git a/lib/net/rte_net.h b/lib/net/rte_net.h
> > index 434435ffa2..3f4c8c58b9 100644
> > --- a/lib/net/rte_net.h
> > +++ b/lib/net/rte_net.h
> > @@ -125,11 +125,22 @@ rte_net_intel_cksum_flags_prepare(struct rte_mbuf *m, uint64_t ol_flags)
> > * Mainly it is required to avoid fragmented headers check if
> > * no offloads are requested.
> > */
> > - if (!(ol_flags & (PKT_TX_IP_CKSUM | PKT_TX_L4_MASK | PKT_TX_TCP_SEG)))
> > + if (!(ol_flags & (PKT_TX_IP_CKSUM | PKT_TX_L4_MASK | PKT_TX_TCP_SEG |
> > + PKT_TX_OUTER_IP_CKSUM)))
> > return 0;
> > - if (ol_flags & (PKT_TX_OUTER_IPV4 | PKT_TX_OUTER_IPV6))
> > + if (ol_flags & (PKT_TX_OUTER_IPV4 | PKT_TX_OUTER_IPV6)) {
> > inner_l3_offset += m->outer_l2_len + m->outer_l3_len;
> > + /*
> > + * prepare outer ipv4 header checksum by setting it to 0,
> > + * in order to be computed by hardware NICs.
> > + */
> > + if (ol_flags & PKT_TX_OUTER_IP_CKSUM) {
> > + ipv4_hdr = rte_pktmbuf_mtod_offset(m,
> > + struct rte_ipv4_hdr *, m->outer_l2_len);
> > + ipv4_hdr->hdr_checksum = 0;
>
> Here we assume that the field is located in the first segment.
> Unlikely but it still could be false. We must handle it properly.
This is specified in the API comment, so I think it has to be checked
by the caller.
> > + }
> > + }
> > /*
> > * Check if headers are fragmented.
> >
>
More information about the stable
mailing list