From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olivier MATZ Subject: Re: [PATCH 00/17] unified packet type Date: Mon, 02 Feb 2015 12:37:31 +0100 Message-ID: <54CF617B.5010009@6wind.com> References: <1421637666-16872-1-git-send-email-helin.zhang@intel.com> <1422501365-12643-1-git-send-email-helin.zhang@intel.com> <54CB879D.2010505@6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit To: "Zhang, Helin" , "dev-VfR2kkLFssw@public.gmane.org" Return-path: In-Reply-To: List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" 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) - the checksum field has been verified by hw, and if wrong, the flag PKT_RX_IP_CKSUM_BAD is set 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