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