On 7/21/22 06:24, Ding, Xuan wrote:
Hi Andrew,
-----Original Message-----
From: Andrew Rybchenko <andrew.rybche...@oktetlabs.ru>
Sent: 2022年7月8日 23:01
To: Wu, WenxuanX <wenxuanx...@intel.com>; tho...@monjalon.net; Li,
Xiaoyun <xiaoyun...@intel.com>; ferruh.yi...@xilinx.com; Singh, Aman Deep
<aman.deep.si...@intel.com>; dev@dpdk.org; Zhang, Yuying
<yuying.zh...@intel.com>; Zhang, Qi Z <qi.z.zh...@intel.com>;
jerinjac...@gmail.com
Cc: step...@networkplumber.org; Ding, Xuan <xuan.d...@intel.com>; Wang,
YuanX <yuanx.w...@intel.com>; Ray Kinsella <m...@ashroe.eu>
Subject: Re: [PATCH v9 2/4] ethdev: introduce protocol hdr based buffer split
On 6/13/22 13:25, wenxuanx...@intel.com wrote:
From: Wenxuan Wu <wenxuanx...@intel.com>
Currently, Rx buffer split supports length based split. With Rx queue
offload RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT enabled and Rx packet
segment
configured, PMD will be able to split the received packets into
multiple segments.
However, length based buffer split is not suitable for NICs that do
split based on protocol headers. Given an arbitrarily variable length
in Rx packet segment, it is almost impossible to pass a fixed protocol
header to driver. Besides, the existence of tunneling results in the
composition of a packet is various, which makes the situation even worse.
This patch extends current buffer split to support protocol header
based buffer split. A new proto_hdr field is introduced in the
reserved field of rte_eth_rxseg_split structure to specify protocol
header. The proto_hdr field defines the split position of packet,
splitting will always happens after the protocol header defined in the
Rx packet segment. When Rx queue offload
RTE_ETH_RX_OFFLOAD_BUFFER_SPLIT is enabled and corresponding protocol
header is configured, driver will split the ingress packets into multiple
segments.
struct rte_eth_rxseg_split {
struct rte_mempool *mp; /* memory pools to allocate segment from */
uint16_t length; /* segment maximal data length,
configures "split point" */
uint16_t offset; /* data offset from beginning
of mbuf data buffer */
uint32_t proto_hdr; /* inner/outer L2/L3/L4 protocol header,
configures "split point" */
There is a big problem here that using RTE_PTYPE_* defines I can't request split
after either TCP or UDP header.
Sorry, for some reason I missed your reply.
Current RTE_PTYPE_* list all the tunnel and L2/L3/L4 protocol headers (both
outer and inner).
Do you mean that we should support higher layer protocols after L4?
I think tunnel and L2/L3/L4 protocol headers are enough.
In DPDK, we don't parse higher level protocols after L4.
And the higher layer protocols are richer, we can't list all of them.
What do you think?
It looks like you don't get my point. You simply cannot say:
RTE_PTYPE_L4_TCP | RTE_PTYPE_L4_UDP since it is numerically equal to
RTE_PTYPE_L4_FRAG. May be the design limitation is acceptable.
I have no strong opinion, but it must be clear for all that the
limitation exists.
};
If both inner and outer L2/L3/L4 level protocol header split can be
supported by a PMD. Corresponding protocol header capability is
RTE_PTYPE_L2_ETHER, RTE_PTYPE_L3_IPV4, RTE_PTYPE_L3_IPV6,
RTE_PTYPE_L4_TCP, RTE_PTYPE_L4_UDP, RTE_PTYPE_L4_SCTP,
RTE_PTYPE_INNER_L2_ETHER, RTE_PTYPE_INNER_L3_IPV4,
RTE_PTYPE_INNER_L3_IPV6, RTE_PTYPE_INNER_L4_TCP,
RTE_PTYPE_INNER_L4_UDP, RTE_PTYPE_INNER_L4_SCTP.
I think there is no point to list above defines here if it is not the only
supported
defines.
Yes, since we use a API to return the protocol header driver supported to split,
there is no need to list the incomplete RTE_PTYPE* here. Please see next
version.
For example, let's suppose we configured the Rx queue with the
following segments:
seg0 - pool0, proto_hdr0=RTE_PTYPE_L3_IPV4, off0=2B
seg1 - pool1, proto_hdr1=RTE_PTYPE_L4_UDP, off1=128B
seg2 - pool2, off1=0B
The packet consists of MAC_IPV4_UDP_PAYLOAD will be split like
following:
seg0 - ipv4 header @ RTE_PKTMBUF_HEADROOM + 2 in mbuf from pool0
seg1 - udp header @ 128 in mbuf from pool1
seg2 - payload @ 0 in mbuf from pool2
Sorry, but I still see no definition what should happen with, for example, ARP
packet with above config.
Thanks, because the following reply was not answered in v8,
the definition has not been added in v9 yet.
"
Our NIC only supports to split the packets into two segments,
so there will be an exact match for the only one protocol header configured.
Back to this
question, for the set of proto_hdrs configured, it can have two behaviors:
1. The aggressive way is to split on longest match you mentioned, E.g. we
configure split
on ETH-IPV4-TCP, when receives ETH-IPV4-UDP or ETH-IPV6, it can also split on
ETH-IPV4
or ETH.
2. A more conservative way is to split only when the packets meet the all
protocol headers
in the Rx packet segment. In the above situation, it will not do split for
ETH-IPV4-UDP
and ETH-IPV6.
I prefer the second behavior, because the split is usually for the inner most
header and
payload, if it does not meet, the rest of the headers have no actual value.
"
Hope to get your insights.
And we will update the doc to define the behavior in next version.
I'm OK with (2) as well. Please, define it in the documentation. Also it
must be clear which segment/mempool is used if a packet is not split.
