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

[Zhang, Helin]

> -----Original Message-----
> From: Ananyev, Konstantin
> Sent: Tuesday, February 3, 2015 1:20 AM
> To: Olivier MATZ; Zhang, Helin; dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH 00/17] unified packet type
> 
> 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

I think packet type and checksum are totally different things in DPDK, though
they might have dependencies in hardware.
Checksum good/bad is still indicated in ol_flags. Packet type is nothing about
checksum.

Regards,
Helin

> 
> >
> > 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