Re: [dpdk-dev] supported packet types

["Ananyev, Konstantin" <konstantin.ananyev@intel.com>]

Hi Olivier,

 
> Hi,
> 
> The following commit introduces a function to list the supported
> packet types of a device:
> 
>   http://dpdk.org/browse/dpdk/commit/?id=78a38edf66
> 
> I would like to know what does "supported" precisely mean.
> Is it:
> 
> 1/ - if a ptype is marked as supported, the driver MUST set
>      this ptype if the packet matches the format described in rte_mbuf.h
> 
>    -> if the ptype is not recognized, the application is sure
>       that the packet is not one of the supported ptype
>    -> but this is difficult to take advantage of this inside an
>       application that supports several different ports model
>       that do not support the same packet types
> 
> 2/ - if a ptype is marked as supported, the driver CAN set
>      the ptype if the packet matches the format described in rte_mbuf.h
> 
>    -> if a ptype is not recognized, the application does a software
>       fallback
>    -> in this case, it would useless to have the get_supported_ptype()
> 
> Can you confirm if the PMDs and l3fwd (the only user) expect 1/
> or 2/ ?

1) 

> 
> Can you elaborate on the advantages of having this API?

Application can rely on information provided by PMD avoid parsing packet manually to recognise it's pytpe.

> 
> And a supplementary question: if a ptype is not marked as supported,
> is it forbidden for a driver to set this ptype anyway?

I suppose it is not forbidden, but there is no guarantee from PMD that it
would be able to recognise that ptype.

Konstantin

> Because we can
> imagine a hardware that can only recognize packets in some conditions
> (ex: can recognize IPv4 if there is no vlan).
> 
> I think properly defining the meaning of "supported" is mandatory
> to have an application beeing able to use this feature, and avoid
> PMDs to behave differently because the API is unclear (like we've
> already seen for other features).
> 
> 
> Thanks,
> Olivier