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

[Zhang, Helin]

> -----Original Message-----
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier MATZ
> Sent: Monday, September 8, 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.

It is a common field which i40e PMD will use it to store the 'packet type ID'. i40e
hardware can recognize more than a hundred of packet types of received packets,
this is quite useful for upper layer stack or application. So this field is quite useful
and will be filled by PMD.
In ixgbe/igb, it has less than 10 packet types which are marked in offload flags. From
now on, it would be better to have new field here to put the hardware offloaded
packet type in and it could be used for future NICs.

> 
> 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.
> 
> 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? 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.
Yes, PMD will fill it. I40e PMD will be the first one, ixgbe/igb can be kept as it is, or
modified to be consistent. It is used for RX side only, and for TX side, it can be
investigated to see if it can be used also. I think some new features in development
can think of that.
Anyway, it is a quite useful field for i40e and future generation of NICs.
> 
> Regards,
> Olivier