Hi

> -----Original Message-----
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Wednesday, October 22, 2014 4:46 PM
> To: Liu, Jijiang
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v6 1/9] librte_mbuf:the rte_mbuf structure
> changes
> 
> 2014-10-21 14:14, Liu, Jijiang:
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > > 2014-10-21 16:46, Jijiang Liu:
> > > > -       uint16_t reserved2;       /**< Unused field. Required for 
> > > > padding
> */
> > > > +
> > > > +       /**
> > > > +        * Packet type, which is used to indicate ordinary L2 packet 
> > > > format
> and
> > > > +        * also tunneled packet format such as IP in IP, IP in GRE, MAC 
> > > > in GRE
> > > > +        * and MAC in UDP.
> > > > +        */
> > > > +       uint16_t packet_type;
> > >
> > > Why not name it "l2_type"?
'packet_type' is for storing the hardware identified packet type upon different 
layers
of protocols (l2, l3, l4, ...).
It is quite useful for user application or middle layer software stacks, it can 
know
what the packet type is without checking the packet too much by software.
Actually ixgbe already has packet types (less than 10), which is transcoded 
into 'ol_flags'.
For i40e, the packet type can represent about 256 types of packet, 'ol_flags' 
does not
have enough bits for it anymore. So put the i40e packet types into mbuf would 
be better.
Also this field can be used for NON-Intel NICs, I think there must be the 
similar concepts
of other NICs. And 16 bits 'packet_type' has severl reserved bits for future 
and NON-Intel NICs.

> >
> > In datasheet, this term is called packet type(s).
> 
> That's exactly the point I want you really understand!
> This is a field in generic mbuf structure, so your datasheet has no value 
> here.
> 
> > Personally , I think packet type is  more clear what meaning of this field 
> > is .
> ^_^
> 
> You cannot add an API field without knowing what will be its generic meaning.
> Please think about it and describe its scope.
> 
> Thanks
> --
> Thomas

Regards,
Helin

Reply via email to