[dpdk-dev] [PATCH 03/13] mbuf: add packet_type field

Liu, Jijiang jijiang.liu at intel.com
Tue Sep 9 05:57:33 CEST 2014


Hi Olivier,

> -----Original Message-----
> From: Zhu, Heqing
> Sent: Tuesday, September 09, 2014 9:48 AM
> To: Wu, Jingjing; Liu, Jijiang; Zhang, Helin
> Cc: Zhu, Heqing
> Subject: FW: [dpdk-dev] [PATCH 03/13] mbuf: add packet_type field
> 
> One of you need respond to this thread? Please make the answer generic and
> easy to understand/accept if possible.
> 
> -----Original Message-----
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier MATZ
> Sent: Monday, September 08, 2014 7:17 PM
> To: Yerden Zhumabekov; Richardson, Bruce; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 03/13] mbuf: add packet_type field
> 
> Hi Yerden,
> 
> On 09/08/2014 12:33 PM, Yerden Zhumabekov wrote:
> > 08.09.2014 16:17, Olivier MATZ пишет:
> >>> --- a/lib/librte_mbuf/rte_mbuf.h
> >>> +++ b/lib/librte_mbuf/rte_mbuf.h
> >>> @@ -146,7 +146,7 @@ struct rte_mbuf {
> >>>  	uint32_t reserved1;     /**< Unused field. Required for padding */
> >>>
> >>>  	/* remaining bytes are set on RX when pulling packet from descriptor
> */
> >>> -	uint16_t reserved2;     /**< Unused field. Required for padding */
> >>> +	uint16_t packet_type;   /**< Type of packet, e.g. protocols used */
> >>>  	uint16_t data_len;      /**< Amount of data in segment buffer. */
> >>>  	uint32_t pkt_len;       /**< Total pkt len: sum of all segments. */
> >>>  	uint16_t l3_len:9;      /**< L3 (IP) Header Length. */
> >>>
> >> This patch adds a new fields that nobody uses. So why should we add it ?
> >
> > I would use it :)
> > It's useful to store the IP protocol number (UDP, TCP etc) and version
> > of IP (4, 6) and then relay packet to specific handler.
> 
> I'm not saying this field is useless. But even if it's useful for some applications
> like yours, it does not mean that it should go in the generic mbuf structure.

In some types of NIC, for an example, Intel Fortville, which supports various packet types, and packet type value is filled in a field of receive Descriptor by HW,
Normally, application analyses easily what incoming packet format is if it know what packet type is. It is a common approach for analyzing packet format.

> Also, for a new field, we should define who is in charge of filling it.
> Is is the driver? Does it mean that all drivers have to be modified to fill it? Or is
> it just a placeholder for applications? In this case, shouldn't we use
> application-specific metadata?

Yes, driver is in charge of filling it if this type of NIC has a packet type filed in receive Descriptor.

> In the other direction (TX), we would also need
> to define if this field must be filled by the application before transmitting a
> mbuf to a driver.

Normally, TX side don't care the packet type, instead, feature offload flag will be used in TX side.
         In RX side, NIC HW analyses incoming packet and know what packet type is, and fill packet type value in Receive Descriptor.
Of course, I also don't object to add a packet type in TX side if mbuf TX space is enough, but from the present point of view, it is not necessary. 

> Regards,
> Olivier

Regards,
Jijiang Liu

  


More information about the dev mailing list