[dpdk-dev] [PATCH] ixgbe: avoid unnessary break when checking at the tail of rx hwring

[Jianbo Liu]

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