From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id B981EA0579; Thu, 8 Apr 2021 09:53:54 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A4D8140698; Thu, 8 Apr 2021 09:53:54 +0200 (CEST) Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) by mails.dpdk.org (Postfix) with ESMTP id 61B9C40138 for ; Thu, 8 Apr 2021 09:53:53 +0200 (CEST) Received: by mail-wr1-f50.google.com with SMTP id b9so1057182wrs.1 for ; Thu, 08 Apr 2021 00:53:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=GD4FQlOHX9gjtSjAeghkEvMfJUdmTnrxLYbBPDvvF/Y=; b=Kh1t5nkwYRVwXvDDs0h+ZiVC5cyhvfpycQXubhEY2z9UufjoWPm1KQzFGHCg3uvI/1 ZxqQz4RkVRf7c0yz+gb+mnLcdfNSyN/68qMXgNBT9uNJRUDtTdGITi+DPk6ziZLSpI17 hCq4riAFUDS/VL3XQZdBu9EvRdfi/GGUMU5mMKXa6eWeM6bGiRi/wvTMcq+V9txcLPyx h5lgKuvoRBON1YgKzLw/TIlqIpphYm67SR4j892pfs4koXYxCr7h0TOqksPZ3KrsmJHe vy8vCASG0/+5UgxIzDO8HcPYijNo5ywpKyP1dHLCYH3o8Q+Rgz3d+mdNq2Nxh7pjcbz5 wJ0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=GD4FQlOHX9gjtSjAeghkEvMfJUdmTnrxLYbBPDvvF/Y=; b=p0C1EX66NGB0W1L9FBwX81bfo4Ky4tKHRXQNQxrMg/Pu1M7y+EftKSSB3vz2PVuGhY 54QDRTSkxbpSGqrb5wdyUKnoj+wOkk34wrlnUfZ8aDxOQBdyBuTy1HLkYYcctehfFQTY 7DU+4BpRXDqMKRLacmJ0/S+m5b5XZCxkMakC5te3BJwPT3tfa9+X/5LZhG8HqdKPVNJg 6RF5knANmbB6O1/mS9oU8FGRcaItzK0Vn6l4Fi7t6F/eJ7Sbu++tW5nouUs8gC2KCV3F YQVBcqY6FCnOR4f2UXRJE4tJVsgtsJjZs8amRTGnDZ6lRkrliiosAYSFcmpPJcmK5rkj Xgyg== X-Gm-Message-State: AOAM533TDQgY23RQDlCMKJ3A762lBdEP8lJ3fwAovvTcLSnC/xIJsj2U oueReEKWto6eApe57TOMhTRfCrT+89lXOQ== X-Google-Smtp-Source: ABdhPJwAjcvra3ttVG+nX/muhidnyQyA5upREXT5rZURz/yutswfm+suP8kBLlrGQaFl4nzZP8xWHQ== X-Received: by 2002:a5d:5641:: with SMTP id j1mr9467443wrw.100.1617868433184; Thu, 08 Apr 2021 00:53:53 -0700 (PDT) Received: from 6wind.com ([2a01:e0a:5ac:6460:c065:401d:87eb:9b25]) by smtp.gmail.com with ESMTPSA id z15sm9390721wml.4.2021.04.08.00.53.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 08 Apr 2021 00:53:52 -0700 (PDT) Date: Thu, 8 Apr 2021 09:53:52 +0200 From: Olivier Matz To: David Marchand Cc: dev@dpdk.org, maxime.coquelin@redhat.com, fbl@sysclose.org, i.maximets@ovn.org, Keith Wiles Message-ID: <20210408075352.GR1650@platinum> References: <20210401095243.18211-1-david.marchand@redhat.com> <20210401095243.18211-3-david.marchand@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210401095243.18211-3-david.marchand@redhat.com> User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [dpdk-dev] [PATCH 2/5] net/tap: do not touch Tx offload flags X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, Apr 01, 2021 at 11:52:40AM +0200, David Marchand wrote: > Tx offload flags are of the application responsibility. > Leave the mbuf alone and check for TSO where needed. > > Signed-off-by: David Marchand Maybe the problem being solved should be better described in the commit log. Is it a problem (other than cosmetic) to touch a mbuf in the Tx function of a driver, where we could expect that the mbuf is owned by the driver? The only problem I can think about is in case we transmit a direct mbuf whose refcnt is increased, but I wonder how much this is really supported: for instance, several drivers add vlans using rte_vlan_insert() in their Tx path. > --- > drivers/net/tap/rte_eth_tap.c | 17 ++++++++++------- > 1 file changed, 10 insertions(+), 7 deletions(-) > > diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c > index c36d4bf76e..285fe395c5 100644 > --- a/drivers/net/tap/rte_eth_tap.c > +++ b/drivers/net/tap/rte_eth_tap.c > @@ -562,6 +562,7 @@ tap_tx_l3_cksum(char *packet, uint64_t ol_flags, unsigned int l2_len, > uint16_t *l4_phdr_cksum, uint32_t *l4_raw_cksum) > { > void *l3_hdr = packet + l2_len; > + uint64_t csum_l4; > > if (ol_flags & (PKT_TX_IP_CKSUM | PKT_TX_IPV4)) { > struct rte_ipv4_hdr *iph = l3_hdr; > @@ -571,13 +572,17 @@ tap_tx_l3_cksum(char *packet, uint64_t ol_flags, unsigned int l2_len, > cksum = rte_raw_cksum(iph, l3_len); > iph->hdr_checksum = (cksum == 0xffff) ? cksum : ~cksum; > } > - if (ol_flags & PKT_TX_L4_MASK) { > + > + csum_l4 = ol_flags & PKT_TX_L4_MASK; > + if (ol_flags & PKT_TX_TCP_SEG) > + csum_l4 |= PKT_TX_TCP_CKSUM; > + if (csum_l4) { > void *l4_hdr; > > l4_hdr = packet + l2_len + l3_len; > - if ((ol_flags & PKT_TX_L4_MASK) == PKT_TX_UDP_CKSUM) > + if (csum_l4 == PKT_TX_UDP_CKSUM) > *l4_cksum = &((struct rte_udp_hdr *)l4_hdr)->dgram_cksum; > - else if ((ol_flags & PKT_TX_L4_MASK) == PKT_TX_TCP_CKSUM) > + else if (csum_l4 == PKT_TX_TCP_CKSUM) > *l4_cksum = &((struct rte_tcp_hdr *)l4_hdr)->cksum; > else > return; > @@ -648,7 +653,8 @@ tap_write_mbufs(struct tx_queue *txq, uint16_t num_mbufs, > if (txq->csum && > ((mbuf->ol_flags & (PKT_TX_IP_CKSUM | PKT_TX_IPV4) || > (mbuf->ol_flags & PKT_TX_L4_MASK) == PKT_TX_UDP_CKSUM || > - (mbuf->ol_flags & PKT_TX_L4_MASK) == PKT_TX_TCP_CKSUM))) { > + (mbuf->ol_flags & PKT_TX_L4_MASK) == PKT_TX_TCP_CKSUM) || > + (mbuf->ol_flags & PKT_TX_TCP_SEG))) { > is_cksum = 1; > > /* Support only packets with at least layer 4 > @@ -742,9 +748,6 @@ pmd_tx_burst(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts) > if (tso) { > struct rte_gso_ctx *gso_ctx = &txq->gso_ctx; > > - /* TCP segmentation implies TCP checksum offload */ > - mbuf_in->ol_flags |= PKT_TX_TCP_CKSUM; > - > /* gso size is calculated without RTE_ETHER_CRC_LEN */ > hdrs_len = mbuf_in->l2_len + mbuf_in->l3_len + > mbuf_in->l4_len; > -- > 2.23.0 >