Hi Jacob, > -----Original Message----- > From: Jerin Jacob <jerinjac...@gmail.com> > Sent: Thursday, April 7, 2022 9:27 PM > To: Wu, WenxuanX <wenxuanx...@intel.com> > Cc: Thomas Monjalon <tho...@monjalon.net>; Andrew Rybchenko > <andrew.rybche...@oktetlabs.ru>; Li, Xiaoyun <xiaoyun...@intel.com>; > Singh, Aman Deep <aman.deep.si...@intel.com>; Zhang, Yuying > <yuying.zh...@intel.com>; Zhang, Qi Z <qi.z.zh...@intel.com>; dpdk-dev > <dev@dpdk.org>; Stephen Hemminger <step...@networkplumber.org>; > Morten Brørup <m...@smartsharesystems.com>; Viacheslav Ovsiienko > <viachesl...@nvidia.com>; Yu, Ping <ping...@intel.com>; Ding, Xuan > <xuan.d...@intel.com>; Wang, YuanX <yuanx.w...@intel.com> > Subject: Re: [v4 1/3] ethdev: introduce protocol type based header split > > On Sat, Apr 2, 2022 at 4:33 PM <wenxuanx...@intel.com> wrote: > > > > From: Xuan Ding <xuan.d...@intel.com> > > > > 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
Proto defines the location in packet for split. Offset defines data buffer from beginning of mbuf data buffer, it can be zero. With proto and offset configured, packets received will be split into two segments. So in this configuration, the seg0 content is UDP header, the seg1 content is the payload. Size of seg0 is size of UDP header, size of seg1 is size of payload. rte_eth_rxseg_split.offset = 2/128 decides the mbuf offset, rather than segment size. > > Also, I don't think we need duplate > rte_eth_rx_header_split_protocol_type instead we can reuse existing > RTE_PTYPE_* flags. That's a good idea. Yes, I can use the RTE_PTYPE_* here. My only concern is the 32-bits RTE_PTYPE_* will run out of the 32-bits reserved fields. If this proposal is agreed, I will use RTE_PTYPE_* instead of rte_eth_rx_header_split_protocol_type. Best Regards, Xuan > > > > 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.
