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

[Jim Thompson <jim@netgate.com>]

> On Sep 8, 2014, at 4:17 AM, Olivier MATZ <olivier.matz@6wind.com> wrote:
> 
> 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.


Funny, but these new fields (and extended mbuf) were prominent during the dpdk summit.

I think it’s going to be quite useful.