> +/** > + * Apply stashing hint to data at a given offset from the start of a > + * received packet. > + */ > +#define RTE_ETH_DEV_STASH_OBJECT_OFFSET 0x0001 > + > +/** Apply stashing hint to an rx descriptor. */ > +#define RTE_ETH_DEV_STASH_OBJECT_DESC 0x0002 > + > +/** Apply stashing hint to a header of a received packet. */ > +#define RTE_ETH_DEV_STASH_OBJECT_HEADER 0x0004 > + > +/** Apply stashing hint to a payload of a received packet. */ > +#define RTE_ETH_DEV_STASH_OBJECT_PAYLOAD 0x0008 > + > +#define __RTE_ETH_DEV_STASH_OBJECT_MASK 0x000f > +/**@}*/
Although I agree these would be sensible parameters, they seem orthogonal to the Ethdev RX port queue capabilities/configuration. The RTE_ETH_DEV_STASH_OBJECT_DESC aligns well; no problem there. How much of a packet is considered the "header"? L3, L4, Outer tunnel header, or both Outer and Inner headers? If it follows the configuration already established through the existing Ethdev APIs on the RX port queue, it aligns well too. Now, it's the data part I'm wondering about: If an RX port queue is configured for receiving into mbufs from one mempool containing 2 KB objects (i.e. segments of 2 KB contiguous RAM), how do the OFFSET, HEADER, and PAYLOAD hints work? And what is the corresponding Ethdev RX queue configuration? Same questions, considering an RX port queue configured for receiving the first 128 B into an mbuf from one mempool and the remaining part of the packet into 2 KB mbufs from another mempool? Please provide some explanatory examples using these APIs along with the existing APIs for setting up the RX port queue. Packets may be jumbo frames, scattered into multiple 2 KB mbufs. That should not make any difference; i.e. I assume the OFFSET, HEADER and PAYLOAD hints are considered at a packet level, not segment level. I also assume IP fragments are treated like any other IP packets; basically, the only difference is the size of the header (it only has the IP header, and no following headers).
