From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id 206741B137 for ; Wed, 13 Feb 2019 10:50:34 +0100 (CET) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us3.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id D4126B8005A; Wed, 13 Feb 2019 09:50:32 +0000 (UTC) Received: from [192.168.38.17] (91.220.146.112) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 13 Feb 2019 09:50:24 +0000 To: Tomasz Kulasek , Olivier Matz CC: , Konstantin Ananyev , "Thomas Monjalon" , Stephen Hemminger References: <1548751746-16030-1-git-send-email-arybchenko@solarflare.com> From: Andrew Rybchenko Message-ID: Date: Wed, 13 Feb 2019 12:50:19 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <1548751746-16030-1-git-send-email-arybchenko@solarflare.com> Content-Language: en-GB X-Originating-IP: [91.220.146.112] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24426.003 X-TM-AS-Result: No-18.310500-8.000000-10 X-TMASE-MatchedRID: 6lay9u8oTUPJM5Ks2Ob22I+YSzwl92XTjLOy13Cgb4/TEy+FT1zrl+7J GcN5XxmLrwvtynGI5cofqXaEwlcZy4BoGyFs+F1Mr9nDy1FvnfnvJY9pBzgg1LyfwLPqtObs5zY xToKgLeT49TeP+hzSpeKOmN63egZIkKjL2IOi2LCiAZ3zAhQYglF5adRR2Ej19chSMsU+J8u+Ci i8OEfkpvDW7JgJ6+4TAAISdkcEFv4TpX/Z22DgprRtO1RC1Ep0myqQJWNsuknWCKzDYkqjyazXk uh6mdZYcsNrEYX6vJTGxHI2HxYHpDblc6Gei4nlIj0zFI5DoJJeCrB32KOS0KMLUT/MIQivCvE6 8u8U9k8R4d+Uvhl0qv1VprTjLOsRw3inhDZkPRlmNCKOCsW/Og3mvPKZj/z+2Yajy1P9W1XdKUS BW7I322+5ieh24ZYRkZOl7WKIImrvXOvQVlExsFZ0V5tYhzdWbGVEmIfjf3t54uc2JxGVoIXguk 8reS71IzDdMEelVcX+xttSL7fL01SLvOXCXTYmtC0g+YcHA5IcADpykT/Gu94ZJMyy7olAJ6smC 1bQcl8= X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--18.310500-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24426.003 X-MDID: 1550051433-fvHJMe1qq81d Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [RFC PATCH] mbuf: move headers not fragmented check to checksum X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 09:50:34 -0000 Ping. Do 2 weeks without reply mean that it looks good and I should send non-RCF version? Andrew. On 1/29/19 11:49 AM, Andrew Rybchenko wrote: > rte_validate_tx_offload() is used in Tx prepare callbacks > (RTE_LIBRTE_ETHDEV_DEBUG only) to check Tx offloads consistency. > Requirement that packet headers should not be fragmented is not > documented and unclear where it comes from except > rte_net_intel_cksum_prepare() functions which relies on it. > > It could be NIC vendor specific driver or hardware limitation, but, > if so, it should be documented and checked in corresponding Tx > prepare callbacks. > > Signed-off-by: Andrew Rybchenko > --- > May be the check should be done in rte_net_intel_cksum_prepare() > under RTE_LIBRTE_ETHDEV_DEBUG only. Mainly I'd like to get feedback > on where the limitation comes from and idea to remove it from > rte_validate_tx_offload(). > > lib/librte_mbuf/rte_mbuf.h | 12 ------------ > lib/librte_net/rte_net.h | 17 +++++++++++++++++ > 2 files changed, 17 insertions(+), 12 deletions(-) > > diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h > index a7f67023a..14a3b472b 100644 > --- a/lib/librte_mbuf/rte_mbuf.h > +++ b/lib/librte_mbuf/rte_mbuf.h > @@ -2257,23 +2257,11 @@ static inline int > rte_validate_tx_offload(const struct rte_mbuf *m) > { > uint64_t ol_flags = m->ol_flags; > - uint64_t inner_l3_offset = m->l2_len; > > /* Does packet set any of available offloads? */ > if (!(ol_flags & PKT_TX_OFFLOAD_MASK)) > return 0; > > - if (ol_flags & PKT_TX_OUTER_IP_CKSUM) > - /* NB: elaborating the addition like this instead of using > - * += gives the result uint64_t type instead of int, > - * avoiding compiler warnings on gcc 8.1 at least */ > - inner_l3_offset = inner_l3_offset + m->outer_l2_len + > - m->outer_l3_len; > - > - /* Headers are fragmented */ > - if (rte_pktmbuf_data_len(m) < inner_l3_offset + m->l3_len + m->l4_len) > - return -ENOTSUP; > - > /* IP checksum can be counted only for IPv4 packet */ > if ((ol_flags & PKT_TX_IP_CKSUM) && (ol_flags & PKT_TX_IPV6)) > return -EINVAL; > diff --git a/lib/librte_net/rte_net.h b/lib/librte_net/rte_net.h > index e59760a0a..bd75aea8e 100644 > --- a/lib/librte_net/rte_net.h > +++ b/lib/librte_net/rte_net.h > @@ -118,10 +118,27 @@ rte_net_intel_cksum_flags_prepare(struct rte_mbuf *m, uint64_t ol_flags) > struct udp_hdr *udp_hdr; > uint64_t inner_l3_offset = m->l2_len; > > + /* > + * Does packet set any of available offloads? > + * Mainly it is required to avoid fragmented headers check if > + * no offloads are requested. > + */ > + if (!(ol_flags & PKT_TX_OFFLOAD_MASK)) > + return 0; > + > if ((ol_flags & PKT_TX_OUTER_IP_CKSUM) || > (ol_flags & PKT_TX_OUTER_IPV6)) > inner_l3_offset += m->outer_l2_len + m->outer_l3_len; > > + /* > + * Check if headers are fragmented. > + * The check could be less strict depending on which offloads are > + * requested and headers to be used, but let's keep it simple. > + */ > + if (unlikely(rte_pktmbuf_data_len(m) < > + inner_l3_offset + m->l3_len + m->l4_len)) > + return -ENOTSUP; > + > if (ol_flags & PKT_TX_IPV4) { > ipv4_hdr = rte_pktmbuf_mtod_offset(m, struct ipv4_hdr *, > inner_l3_offset);