Re: [dpdk-users] i40e vPMD fix out of order Rx read issue

[Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>]

> <snip>
> 
> Hi Qi,
> 	Thank you so much for your explanation. I am trying to review this
> patch and I have further questions on the NIC behavior.
> 
> > >> > > Subject: RE: i40e vPMD fix out of order Rx read issue
> > >> > >
> > >> > > Hi Qi,
> > >> > >
> > >> > > Thanks for your explanation!
> > >> > > I did some testing and found the barriers caused a big drop in
> > >> > > RFC2544 NDR performance on aarch64, how about it on X86?
> > >> > For x86, I think we don't have performance drop, the memory
> > >> > barrier just change the compiler's behavior to avoid generate out
> > >> > of order read instructions, and x86 guarantee no out of read
> > >> > execution, so it does not add new instructions that cost CPU cycles.
> > >> >
> > >> > > Is it possible to count DD bits in a way of surviving across
> > >> > > the out-of-order descriptors reading?
> > >> >
> > >> > I think it is possible, but this will impact performance on x86,
> > >> > but for aarch64, you can try out to see if that benefit and do
> > >> > proper optimization on related vPMD implementation.
> > >> The patches for aarch64 are in community review, and performances
> > >> gain were measured both for ixgbe and i40e vPMD. Very appreciate if
> > >> you can further review and comment.
> > >> Here are the patch links:
> > >> IXGBE vPMD:
> > >> http://patches.dpdk.org/patch/57649/
> > >> http://patches.dpdk.org/patch/57650/
> > >> I40e vPMD:
> > >> http://patches.dpdk.org/cover/57651/
> > >> http://patches.dpdk.org/patch/57652/
> > >
> > >
> > >
> > >> > >
> > >> > > Best Regards,
> > >> > > Gavin
> > >> > >
> > >> > > > -----Original Message-----
> > >> > > > From: Zhang, Qi Z <qi.z.zhang@intel.com>
> > >> > > > Sent: Thursday, July 25, 2019 8:11 PM
> > >> > > > To: Gavin Hu (Arm Technology China) <Gavin.Hu@arm.com>;
> > >> > > > Richardson, Bruce <bruce.richardson@intel.com>; Ananyev,
> > >> > > > Konstantin <konstantin.ananyev@intel.com>
> > >> > > > Cc: users@dpdk.org; Honnappa Nagarahalli
> > >> > > > <Honnappa.Nagarahalli@arm.com>; Phil Yang (Arm Technology
> > >> > > > China) <Phil.Yang@arm.com>
> > >> > > > Subject: RE: i40e vPMD fix out of order Rx read issue
> > >> > > >
> > >> > > > Hi Gavin:
> > >> > > >
> > >> > > > in vPMD, we read 4 or 8 packets as batch, we count DD bits
> > >> > > > for packet received, but not check the if they are continues
> > >> > > > or not, we assume it should always be 1000, 1100, 1110, 1111
> > >> > > > ....(take batch size is 4 as
> > >> > > > example) while the out of order read instruction generated by
> > >> > > > compiler will cause driver to get un-continues DD bits, like
> > >> > > > 1011, the descriptor on the hole actually is invalid since
> > >> > > > when it is read , descriptor is not write back yet, but we
> > >> > > > still process this as 1110, it cause
> > >> > an
> > >> > > corrupted mbuf returned.
> 1) vPMD reads the descriptors in the reverse order. Let us number them D4,
> D3, D2, D1 for this discussion (1 to 4 is the order of the incoming packets,
> using D1 to D4 respectively). If DD bit for D4 is 1, does the NIC guarantee
> that the DD bit for D3, D2 and D1 will be 1?
The reason I ask this question is: looking at the non-vector PMD, function i40e_rx_scan_hw_ring, the code counts the number of descriptors with DD bit set to 1. However, it does not check if the descriptors with DD bit set to 1 are contiguous. This makes me believe that NIC will ensure that DD bits are set in order. i.e. in the example above (assuming we are reading the descriptors in order) if DD bit for D4 is set to 1, it is guaranteed that DD bits for D3, D2, D1 are also set.

> 2) There is a comment in the code that says 'Read desc statuses backwards to
> avoid race condition'. Can you elaborate on what is the race condition?
> I referred to [1] and I cannot find much information about this race condition.
> Am I referring to the correct document?
> 
> [1] Intel(r) Ethernet Controller X710/XXV710/XL710 Datasheet
> 
> > >> > > >
> > >> > > > hope this is helpful.
> > >> > > >
> > >> > > > Regards
> > >> > > > Qi
> > >> > > >
> > >> > > > > -----Original Message-----
> > >> > > > > From: Gavin Hu (Arm Technology China)
> > >> > > > > [mailto:Gavin.Hu@arm.com]
> > >> > > > > Sent: Thursday, July 25, 2019 5:57 PM
> > >> > > > > To: Zhang, Qi Z <qi.z.zhang@intel.com>; Richardson, Bruce
> > >> > > > > <bruce.richardson@intel.com>; Ananyev, Konstantin
> > >> > > > > <konstantin.ananyev@intel.com>
> > >> > > > > Cc: users@dpdk.org; Honnappa Nagarahalli
> > >> > > > > <Honnappa.Nagarahalli@arm.com>; Phil Yang (Arm Technology
> > >> > > > > China) <Phil.Yang@arm.com>
> > >> > > > > Subject: i40e vPMD fix out of order Rx read issue
> > >> > > > >
> > >> > > > > Hi Qi,
> > >> > > > >
> > >> > > > > I am working on optimizing the i40e vPMD on aarch64 and I
> > >> > > > > see this patch relevant.
> > >> > > > > Could you illuminate what issue this patch was fixing?
> > >> > > > > I understand the PMD works at the driver layer, for
> > >> > > > > delivery of
> > >> > > > > L2
> > >> > packets.
> > >> > > > > It does not own the responsibility to keep order(the
> > >> > > > > responsibility lies with
> > >> > > > the
> > >> > > > > protocol stack, like TCP)?
> > >> > > > >
> > >> > > > > http://patches.dpdk.org/patch/16665/
> > >> > > > >
> > >> > > > > Best regards,
> > >> > > > > Gavin
> > >> > > > >
> <snip>