Hi Olivier > -----Original Message----- > From: Olivier MATZ [mailto:olivier.matz at 6wind.com] > Sent: Tuesday, November 25, 2014 8:38 PM > To: Zhang, Helin; Ananyev, Konstantin; 'dev at dpdk.org' > Cc: 'jigsaw at gmail.com' > Subject: Re: [dpdk-dev] [PATCH v2 06/13] mbuf: add functions to get the name > of > an ol_flag > > Hi Helin, > > On 11/25/2014 01:15 PM, Zhang, Helin wrote: > >>>> I would be in favor of removing them, or at least the following > >>>> ones (I don't understand how they can help the application): > >>>> > >>>> - PKT_RX_OVERSIZE: Num of desc of an RX pkt oversize. > >>>> - PKT_RX_HBUF_OVERFLOW: Header buffer overflow. > >>>> - PKT_RX_RECIP_ERR: Hardware processing error. > >>>> - PKT_RX_MAC_ERR: MAC error. > >>> > >>> Tend to agree... > >>> Or probably collapse these 4 flags into one: flag PKT_RX_ERR or something. > >>> Might be still used by someone for debugging purposes. > >>> Helin, what do you think? > >> > >> As there is no answer, I suppose you don't care these flags any more. > >> So we can just remove them, right? > > Sorry, I think I care it a bit. I have a lot of emails to be dealt with, > > due to the > whole week training. > > Yes, it was added there before new mbuf defined. Why zero? Because of lack > of bits for them. > > Unfortunately, I forgot to add them with correct values after new mbuf > introduced. > > Thank you so much for spotting it out! > > > > The error flags were added according to the errors defined by FVL > > datasheet. It could be helpful for middle layer software or > > applications with the specific errors identified. I'd prefer to add the > > correct > values for those flags. What do you think? > > Could you elaborate about why it could be useful for an application to have > this > flag in the mbuf? When these flags are set, is the data still present in the > mbuf? > How can the application use this data if the hardware says "there is an error > in > the packet"? That mbuf has already been filled with data, even error happens. The error flags can be used to indicate if the data is valid or not. Though it may not need too many error flags, but error flags with specific root causes could be helpful for users to know what happens.
> > I think a stats counter would do the job here. It already supports statistics collection in i40e. > > Regards, > Olivier Regards, Helin
