> -----Original Message----- > From: Zhang, Helin > Sent: Tuesday, November 18, 2014 2:12 PM > To: Ananyev, Konstantin; Liu, Jijiang; dev at dpdk.org > Subject: RE: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e > > > > > -----Original Message----- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ananyev, Konstantin > > Sent: Tuesday, November 18, 2014 7:33 PM > > To: Liu, Jijiang; dev at dpdk.org > > Subject: Re: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e > > > > Hi Frank, > > > > > -----Original Message----- > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jijiang Liu > > > Sent: Tuesday, November 18, 2014 7:37 AM > > > To: dev at dpdk.org > > > Subject: [dpdk-dev] [PATCH 0/4] Translate packet types for i40e > > > > > > The i40e NIC can recognize many packet types, including ordinary L2 > > > packet format and tunneling packet format such as IP in IP, IP in GRE, > > > MAC in > > GRE and MAC in UDP. > > > > > > This patch set provides abstract definitions of packet types, which > > > can help user to use these packet types directly in their applications to > > > speed > > up receive packet analysis. > > > > > > Moreover, this patch set translates i40e packet types to abstract > > > packet types in i40e driver, and make the corresponding changes in test > > applications. > > > > > > Jijiang Liu (4): > > > Add packet type and IP header check in rte_mbuf > > > Remove the PKT_RX_TUNNEL_IPV4_HDR and the > > PKT_RX_TUNNEL_IPV6_HDR > > > Translate i40e packet types > > > Make the corresponding changes in test-pmd > > > > > > app/test-pmd/csumonly.c | 12 +- > > > app/test-pmd/rxonly.c | 15 +- > > > lib/librte_mbuf/rte_mbuf.h | 225 ++++++++++++++- > > > lib/librte_pmd_i40e/i40e_rxtx.c | 604 > > > +++++++++++++++++++++------------------ > > > 4 files changed, 569 insertions(+), 287 deletions(-) > > > > > > > The patch looks good to me in general. > > Though I think it is not complete: we need to make sure that all PMDs RX > > functions will set mbuf's packet_type to the defined value. > We met quite a lot of similar situations, we designed a new way for i40e, then > have to rework igb/ixgbe. E.g. configuring reta, flow director, etc. > If possible, send the patch set as smaller as possible might be better. I > guess > igb/ixgbe will be done soon later. > > > As right now, only i40e implementation can distinguish packet_type > > properly, I > > think all other PMDs for the freshly received packet should do: > > mbuf->packet_type = RTE_PTYPE_UNDEF; > If I am not wrong, RTE_PTYPE_UNDEF can be 0, is packet_type in mbuf > initialized to 0?
Yes RTE_PTYPE_UNDEF == 0 > If yes, nothing needs to be done in igb/ixgbe for now. Could you explain to me why is that? As I remember none of our RX functions reset the whole mbuf to all zeroes. None of them even call rte_pktmbuf_reset() for performance reasons. So what/who would prevent reset packet_type of the freshly received packet_type to zero? BTW, I think that rte_pktmbuf_reset() need to reset packet_type too. > > > > > Another thing: right now mbuf's packet_type is uint16_t. > > While enum rte_eth_packet_type will be interpreted by the compiler as 'int' > > (32bits). > > We can either change enum to a lot of defines (which I don't really like to > > do) or > > probably just add a comment somewhere that enum rte_eth_packet_type > > should never exceed UINT16_MAX value? > > > > Konstantin > > > > > -- > > > 1.7.7.6 > > Regards, > Helin
