From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id EA2C8A05D3 for ; Fri, 29 Mar 2019 14:31:02 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 04FB02BF4; Fri, 29 Mar 2019 14:31:01 +0100 (CET) Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id B07A81B05 for ; Fri, 29 Mar 2019 14:30:59 +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-us4.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 2EC32140088; Fri, 29 Mar 2019 13:30:57 +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; Fri, 29 Mar 2019 13:30:51 +0000 To: Olivier Matz CC: Tomasz Kulasek , , "Konstantin Ananyev" , Thomas Monjalon , Ferruh Yigit References: <1548751746-16030-1-git-send-email-arybchenko@solarflare.com> <1550557852-21882-1-git-send-email-arybchenko@solarflare.com> <9483be25-fc2b-9d0e-81d2-24295d68a07f@solarflare.com> <20190329130949.tjjo2e5onssvoru4@platinum> From: Andrew Rybchenko Message-ID: <4a844c8d-d466-d58e-80a3-9473b1943c80@solarflare.com> Date: Fri, 29 Mar 2019 16:30:48 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <20190329130949.tjjo2e5onssvoru4@platinum> Content-Type: text/plain; charset="UTF-8"; format="flowed" Content-Transfer-Encoding: 7bit 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-24518.003 X-TM-AS-Result: No-13.350700-8.000000-10 X-TMASE-MatchedRID: UuaOI1zLN1gOwH4pD14DsPHkpkyUphL9pfVcx39Kq+4AhmnHHeGnva8v ojPaFfO4EQ/pXp0YnfYndz94Tmfpa4BoGyFs+F1Mr9nDy1Fvnfnj5lyuq8IOQSz+5QCTrE/s+Vi hXqn9xLF/zqWHr6CN2Ov4h1UdnDHwoVmYC/wuD3VfLa2Qr61pJDpA2zZYJjv11R8gEUonndSwDd SthfCfMFca4ikIJKKYdA6sjiuxK/FYX0q7tjxibcOD5TU1KZy5DvJ43UwBMxQUnhXZChKvF6f9v 8vBNUVer9QfHPpB/z9DQ02TuhF4zhDmHEk4zuFDsaPcs3T4TL2YasbATu5ay0UNHQAoZf5crOrd UH2aAHeYQ8NKCuMAbh9l1zPMOb+6TX7PJ/OU3vKDGx/OQ1GV8rHlqZYrZqdI+gtHj7OwNO0PXZP urZ0hS+Dz7R6DFyP0OJj8fhM0edDUca+1wbuCoybO3KYWhJkH X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--13.350700-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24518.003 X-MDID: 1553866258-IhEaZd0pje-m Subject: Re: [dpdk-dev] [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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190329133048.bOku7seChiHWgW7M8WJGwDniq3_4eVBCEiXwbuEif5g@z> Hi Olivier, On 3/29/19 4:09 PM, Olivier Matz wrote: > Hi Andrew, > > On Thu, Mar 28, 2019 at 08:04:31PM +0300, Andrew Rybchenko wrote: >> Ping? (I have a number of net/sfc patches which heavily depend on this >> one and must not be applied without this one) >> >> Andrew. >> >> On 2/19/19 9:30 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 >>> Acked-by: Konstantin Ananyev >>> --- >>> Looks good to me, though extra-testing would be needed. >>> Konstantin Ananyev >>> >>> 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 d961cca..73daa81 100644 >>> --- a/lib/librte_mbuf/rte_mbuf.h >>> +++ b/lib/librte_mbuf/rte_mbuf.h >>> @@ -2257,23 +2257,11 @@ static inline int rte_pktmbuf_chain(struct rte_mbuf *head, struct rte_mbuf *tail >>> 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 e59760a..bd75aea 100644 >>> --- a/lib/librte_net/rte_net.h >>> +++ b/lib/librte_net/rte_net.h >>> @@ -118,10 +118,27 @@ uint32_t rte_net_get_ptype(const struct rte_mbuf *m, >>> 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); > > To summarize, the previous code was in a generic part, only enabled if > RTE_LIBRTE_ETHDEV_DEBUG is set, and it is moved in an intel-specific part, > but always enabled. Am I correct? Yes, correct. > So it may have a performance impact on intel NICs. Shouldn't it be under > a debug option? Yes, to be 100% equivalent. May be making these checks non-debug is a separate story since IMHO these checks should be non-debug. Below code really depends on these checks and if the condition is violated it will read and could write outside of provided buffer (bad checksums, spoiled memory etc). I'll send v2 shortly with RTE_LIBRTE_ETHDEV_DEBUG to make it easy to pickup finally chosen version. Thanks, Andrew.