From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by smtp.lore.kernel.org (Postfix) with ESMTP id 89D1EC433F5 for ; Tue, 4 Oct 2022 08:22:49 +0000 (UTC) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BBD9040DDC; Tue, 4 Oct 2022 10:22:48 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 8CB3B40A87 for ; Tue, 4 Oct 2022 10:22:46 +0200 (CEST) Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 8F2C05D; Tue, 4 Oct 2022 11:22:45 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 8F2C05D DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1664871765; bh=fMwwpSxTF5MfGv9q6UZOlVj7Y80CdSpohbX4LX/cHkE=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=O8KdGt3Yj6Ggg2xefSxfJ92us5sqHv2cBcDPXkouDONm2E8mSNSSkWkhEf8rvMQuv yMv6IikTi+NWr4ndKnZyK0NgWEunCSUyUBzv1qpNeqOfENuLop9xjynJ2G08af3Zht 1j+eEGo+LqpqO6Si6eylURhiQghoul+v7hcxKbaw= Message-ID: <6420052f-5f21-2416-362a-f1a0527924d2@oktetlabs.ru> Date: Tue, 4 Oct 2022 11:22:44 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.0 Subject: Re: [PATCH v7 2/4] ethdev: introduce protocol hdr based buffer split Content-Language: en-US To: "Wang, YuanX" , "dev@dpdk.org" , Thomas Monjalon , Ferruh Yigit Cc: "ferruh.yigit@xilinx.com" , "mdr@ashroe.eu" , "Li, Xiaoyun" , "Singh, Aman Deep" , "Zhang, Yuying" , "Zhang, Qi Z" , "Yang, Qiming" , "jerinjacobk@gmail.com" , "viacheslavo@nvidia.com" , "stephen@networkplumber.org" , "Ding, Xuan" , "hpothula@marvell.com" , "Tang, Yaqi" References: <20220812181552.2908067-1-yuanx.wang@intel.com> <20221001210521.15955-1-yuanx.wang@intel.com> <20221001210521.15955-3-yuanx.wang@intel.com> <29eb4f17-30a1-fff8-7be4-0092dbd79f5c@oktetlabs.ru> From: Andrew Rybchenko Organization: OKTET Labs In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 On 10/4/22 05:48, Wang, YuanX wrote: > Hi Andrew, > >> -----Original Message----- >> On 10/2/22 00:05, Yuan Wang wrote: >>> + >>> + /* skip the payload */ >> >> Sorry, it is confusing. What do you mean here? > > Because setting n proto_hdr will generate (n+1) segments. If we want to split the packet into n segments, we only need to check the first (n-1) proto_hdr. > For example, for ETH-IPV4-UDP-PAYLOAD, if we want to split after the UDP header, we only need to set and check the UDP header in the first segment. > > Maybe mask is not a good way, so we will use index to filter out the check of proto_hdr inside the last segment. I see your point and understand the problem now. Thinking a bit more about it I realize that consistency check here should be more sophisticated. It should not allow: - seg1 - length-based, seg2 - proto-based, seg3 - payload - seg1 - proto-based, seg2 - legnth-based, seg3 - proto-based, seg4 - payload I.e. no protocol-based split after length-based. But should allow: - seg1 - proto-based, seg2 - legnth-based, seg3 - payload I.e. length based split after protocol-based. Taking the last point above into account, proto_hdr in the last segment should be 0 like in length-based split (not RTE_PTYPE_ALL_MASK). It is an interesting question how to request: - seg1 - ETH, seg2 - IPv4, seg3 - UDP, seg4 - payload Should we really repeat ETH in seg2->proto_hdr and seg3->proto_hdr header and IPv4 in seg3->proto_hdr again? I tend to say no since when packet comes to seg2 it already has no ETH header. If so, how to handle configuration when ETH is repeat in seg2? For example, - seg1 ETH+IPv4+UDP - seg2 ETH+IPv6+UDP - seg2 0 Should we deny it or should we define behaviour like. If a packet does not match segX proto_hdr, the segment is skipped and segX+1 considered. Of course, not all drivers/HW supports it. If so, such configuration should be just discarded by the driver itself.