[dpdk-dev] supported packet types
Ananyev, Konstantin
konstantin.ananyev at intel.com
Fri Apr 29 18:03:46 CEST 2016
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
More information about the dev
mailing list