On Thu, Mar 17, 2016 at 10:20:01AM +0800, Jianbo Liu wrote: > On 16 March 2016 at 19:14, Bruce Richardson <bruce.richardson at intel.com> > wrote: > > On Wed, Mar 16, 2016 at 03:51:53PM +0800, Jianbo Liu wrote: > >> Hi Wenzhuo, > >> > >> On 16 March 2016 at 14:06, Lu, Wenzhuo <wenzhuo.lu at intel.com> wrote: > >> > HI Jianbo, > >> > > >> > > >> >> -----Original Message----- > >> >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jianbo Liu > >> >> Sent: Monday, March 14, 2016 10:26 PM > >> >> To: Zhang, Helin; Ananyev, Konstantin; dev at dpdk.org > >> >> Cc: Jianbo Liu > >> >> Subject: [dpdk-dev] [PATCH] ixgbe: avoid unnessary break when checking > >> >> at the > >> >> tail of rx hwring > >> >> > >> >> When checking rx ring queue, it's possible that loop will break at the > >> >> tail while > >> >> there are packets still in the queue header. > >> > Would you like to give more details about in what scenario this issue > >> > will be hit? Thanks. > >> > > >> > >> vPMD will place extra RTE_IXGBE_DESCS_PER_LOOP - 1 number of empty > >> descriptiors at the end of hwring to avoid overflow when do checking > >> on rx side. > >> > >> For the loop in _recv_raw_pkts_vec(), we check 4 descriptors each > >> time. If all 4 DD are set, and all 4 packets are received.That's OK in > >> the middle. > >> But if come to the end of hwring, and less than 4 descriptors left, we > >> still need to check 4 descriptors at the same time, so the extra empty > >> descriptors are checked with them. > >> This time, the number of received packets is apparently less than 4, > >> and we break out of the loop because of the condition "var != > >> RTE_IXGBE_DESCS_PER_LOOP". > >> So the problem arises. It is possible that there could be more packets > >> at the hwring beginning that still waiting for being received. > >> I think this fix can avoid this situation, and at least reduce the > >> latency for the packets in the header. > >> > > Packets are always received in order from the NIC, so no packets ever get > > left > > behind or skipped on an RX burst call. > > > > /Bruce > > > > I knew packets are received in order, and no packets will be skipped, > but some will be left behind as I explained above. > vPMD will not received nb_pkts required by one RX burst call, and > those at the beginning of hwring are still waiting to be received till > the next call. > > Thanks! > Jianbo HI Jianbo,
ok, I understand now. I'm not sure that this is a significant problem though, since we are working in polling mode. Is there a performance impact to your change, because I don't think that we can reduce performance just to fix this? Regards, /Bruce