On 18 March 2016 at 18:03, Bruce Richardson <bruce.richardson at intel.com> wrote: > 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 It will be a problem because the possibility could be high. Considering rx hwring size is 128 and rx burst is 32, the possiblity can be 32/128. I know this change is critical, so I want you (and maintainers) to do full evaluations about throughput/latency..before making conclusion.
Jianbo
