[dpdk-dev] [PATCH 00/17] unified packet type

Ananyev, Konstantin konstantin.ananyev at intel.com
Mon Feb 2 18:20:12 CET 2015


Hi Olivier,

> -----Original Message-----
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier MATZ
> Sent: Monday, February 02, 2015 11:38 AM
> To: Zhang, Helin; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 00/17] unified packet type
> 
> Hi Helin,
> 
> On 02/02/2015 03:44 AM, Zhang, Helin wrote:
> >>>> Let's take a simple example. Imagine a hardware-1 that is able to
> >>>> recognize an IP packet by checking the ethertype and that the IP
> >>>> version is set to 4.
> >>>> Another hardware-2 recognize an IP packet by checking the ethertype,
> >>>> the IP version and that the IP length is correct compared to m_len(m).
> >>>>
> >>>> For the same packet, both hardwares will return RTE_PTYPE_L3_IPV4,
> >>>> but they don't do the same checks on the packet. As I want my
> >>>> application behave exactly the same whatever the hardware, I need to
> >>>> know what checks are done in hardware, so I can decide what checks
> >>>> must be done in my application.
> >>>>
> >>>> Example of definition: RTE_PTYPE_L3_IPV4 means that ethertype is
> >>>> 0x0800 and IP.version is 4.
> >>>>
> >>>> It means that I can skip these 2 tests in my application if I have
> >>>> this packet_type, but all other checks must be done in software (ip
> >>>> length, flags, checksum, ...)
> >>>>
> >>>> For each packet type, we need a definition like above, and we must
> >>>> check that all drivers setting a packet type behave like described.
> > Hmm, I think the packet_type may need to be renamed to else, like offload_packet_type.
> > It is just for hardware reported packet type information. It is not for all
> > information of a packet.
> > As different hardware may have different capability, it cannot report the same
> > in mbuf among different hardware for the same packet.
> > With your question, I think the hardware capability flags may be needed. Applications
> > can query the packet type capabilities on each port, then it knows what type of packet
> > type information can be reported by the corresponding hardware.
> > What do you think? And are they any better ideas from you?
> 
> I'm not sure renaming the field would change something here.
> 
> The high-level question is: how a software can take advantage of this
> information given by the hardware? If the same packet_type does not
> have the same meaning depending on the hardware, it's not worth having
> this info.
> 
> I think the API should describe for each packet type what can be
> expected by the application. Here is an example. When a driver sets the
> RTE_PTYPE_L3_IPV4 type, it means that:
> 
> - the layer 3 is identified as IP by underlying layer (ex: ethertype=IP
>   if layer 2 is ethernet)
> - the IP version field is 4
> - there is no IP options (i.e the size of header is 20)

Yes, I suppose that's what supported HW can guarantee when RTE_PTYPE_L3_IPV4 is set.

> - the checksum field has been verified by hw, and if wrong, the
>   flag PKT_RX_IP_CKSUM_BAD is set

Hmm, why is that?
As I remember on many devices it is configurable by SW should HW do RX checksum offload or not.
>From DPDK point of view there is hw_ip_checksum field in rte_eth_rxmode.
So it is a possible situation, when at RX HW does packet type determination, but doesn't make L3/L4
checksum calculation.

I suppose for checksum(s) it should be a separate flags (in ol_flags) with 3 possible values:
CKSUM_UNKNOWN, CKSUM_BAD, CKSUM_OK.

Konstantin

> 
> If the hardware is not able to give all this information, there are
> 2 solutions:
> - do the remaining tests in the driver
> - or set l3 pkt_type to unknown
> 
> All other conditions that are not described in the API should be checked
> by the applition if it needs the information (ex: check that IP dest
> address is legal, that ip->len is >= 20, ...).
> 
> 
> If we are able to describe this for all packet types, it would really
> help application to take advantage of these packet types.
> 
> Regards,
> Olivier


More information about the dev mailing list