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

Olivier MATZ olivier.matz at 6wind.com
Mon Sep 8 13:17:18 CEST 2014


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.

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.

Regards,
Olivier


More information about the dev mailing list