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 BF2A3A050B; Thu, 7 Apr 2022 15:27:07 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 842A74068B; Thu, 7 Apr 2022 15:27:07 +0200 (CEST) Received: from mail-io1-f48.google.com (mail-io1-f48.google.com [209.85.166.48]) by mails.dpdk.org (Postfix) with ESMTP id 572C040689 for ; Thu, 7 Apr 2022 15:27:06 +0200 (CEST) Received: by mail-io1-f48.google.com with SMTP id b16so6738865ioz.3 for ; Thu, 07 Apr 2022 06:27:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kpCQpFXvWmJ7cKE4UiZ2014TrSAKBYHmkskmu/Ox8GM=; b=nowL2Pzu9udkvpq4oU/f3gycRYXXhNFNhsNyhZvKWhwf74FSIIl4A3ECd8rIt3sRqs W9wnEwIOZBPZWHkALiZZryfZ5fjgioPWUR2N+RkNQJRm35rwKraVioAYB0bxjMQem8iQ L6DoNEXVnisxYvk+Zu+EgmQBubejRIPyQubTtzvFNSD71Vd41YV+pN3JaG3vqyygbIxQ nyrAiH/3RsDQOd4gaKuV7Rpdkpw+aSAPQkb6HJHKS99hawtxFrVKvKk43AMdwBrMwsdZ jx5vvii8hPcRrFZxQAOolw7ntqTx5086tgQaA1zxDXsqO2HGZI6vK8qfMSUB8r6QHUh7 oREw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kpCQpFXvWmJ7cKE4UiZ2014TrSAKBYHmkskmu/Ox8GM=; b=SZJgnYCHTmABOxRtnwXwVnWMbM8vEOU4g1PcNopupGB9175Frj4xqdMnBL2aHy9A90 4DqwX/qBY9krkDWSednSfHeNfcUgXqZsPZxbFzPo+2uDd+E3PZUpvP1gFLj14Vwqx02F Q5klQfEQ8u/ePsxuTx1wmBQjXNlotJ8j/oPS3bO9UWXuJBTFHDxmTeRysoPEwPYO0D8y Yw30nb4eHl90k6dqT5WhIV/XlUtRJx6doAX71gbG4HahihQHuogZLobVSG8Cx5LrDf2x flUgTBDN9lSdRrE44B4YgHUXru18kNm77bjxgfUzy2UafY9CtcVeeryPK9vlCVBUCCmc vKeg== X-Gm-Message-State: AOAM531D9w5g4xmLarNr7wErLnsb7U+qSbkNCMdsdkVVm78wDZ8dikhQ KuK1jvTpip9yMydGVicdEe9Zku+9VBMkftZ/Ku8= X-Google-Smtp-Source: ABdhPJwnxzjAyuf1Zw9kbsy049NVtYGmEPDYzP25jAapcmceE005RDZPpp2vjKwyulTHT3U2hPuu0pis7lVh9ALJ7os= X-Received: by 2002:a05:6602:185a:b0:645:d914:35e9 with SMTP id d26-20020a056602185a00b00645d91435e9mr6178180ioi.154.1649338025686; Thu, 07 Apr 2022 06:27:05 -0700 (PDT) MIME-Version: 1.0 References: <20220303060136.36427-1-xuan.ding@intel.com> <20220402104109.472078-1-wenxuanx.wu@intel.com> <20220402104109.472078-2-wenxuanx.wu@intel.com> In-Reply-To: <20220402104109.472078-2-wenxuanx.wu@intel.com> From: Jerin Jacob Date: Thu, 7 Apr 2022 18:56:39 +0530 Message-ID: Subject: Re: [v4 1/3] ethdev: introduce protocol type based header split To: wenxuanx.wu@intel.com Cc: Thomas Monjalon , Andrew Rybchenko , Xiaoyun Li , aman.deep.singh@intel.com, yuying.zhang@intel.com, Qi Zhang , dpdk-dev , Stephen Hemminger , =?UTF-8?Q?Morten_Br=C3=B8rup?= , Viacheslav Ovsiienko , ping.yu@intel.com, Xuan Ding , Yuan Wang Content-Type: text/plain; charset="UTF-8" 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 Sat, Apr 2, 2022 at 4:33 PM wrote: > > From: Xuan Ding > > Header split consists of splitting a received packet into two separate > regions based on the packet content. The split happens after the > packet header and before the packet payload. Splitting is usually between > the packet header that can be posted to a dedicated buffer and the packet > payload that can be posted to a different buffer. > > Currently, Rx buffer split supports length and offset based packet split. > Although header split is a subset of buffer split, configuring buffer > split based on length is not suitable for NICs that do split based on > header protocol types. Because tunneling makes the conversion from length > to protocol type impossible. > > This patch extends the current buffer split to support protocol type and > offset based header split. A new proto field is introduced in the > rte_eth_rxseg_split structure reserved field to specify header protocol > type. With Rx offload flag RTE_ETH_RX_OFFLOAD_HEADER_SPLIT enabled and > protocol type configured, PMD will split the ingress packets into two > separate regions. Currently, both inner and outer L2/L3/L4 level header > split can be supported. > > For example, let's suppose we configured the Rx queue with the > following segments: > seg0 - pool0, off0=2B > seg1 - pool1, off1=128B > > With header split type configured with RTE_ETH_RX_HEADER_SPLIT_UDP, > the packet consists of MAC_IP_UDP_PAYLOAD will be split like following: > seg0 - udp header @ RTE_PKTMBUF_HEADROOM + 2 in mbuf from pool0 If we set rte_eth_rxseg_split::proto = RTE_ETH_RX_HEADER_SPLIT_UDP and rte_eth_rxseg_split.offset = 2, What will be the content for seg0, Will it be, - offset as Starts atUDP Header - size of segment as MAX(size of UDP header + 2, 128(as seg 1 start from128). Right? If not, Please describe Also, I don't think we need duplate rte_eth_rx_header_split_protocol_type instead we can reuse existing RTE_PTYPE_* flags. > seg1 - payload @ 128 in mbuf from pool1 > > The memory attributes for the split parts may differ either - for example > the mempool0 and mempool1 belong to dpdk memory and external memory, > respectively.