Hi Vlad, > -----Original Message----- > From: Vlad Zolotarov [mailto:vladz at cloudius-systems.com] > Sent: Wednesday, August 19, 2015 11:03 AM > To: Ananyev, Konstantin; Lu, Wenzhuo > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1 for > all NICs but 82598 > > > > On 08/19/15 10:43, Ananyev, Konstantin wrote: > > Hi Vlad, > > Sorry for delay with review, I am OOO till next week. > > Meanwhile, few questions/comments from me. > > Hi, Konstantin, long time no see... ;) > > > > >>>>>> This patch fixes the Tx hang we were constantly hitting with a > >> seastar-based > >>>>>> application on x540 NIC. > >>>>> Could you help to share with us how to reproduce the tx hang issue, > >> with using > >>>>> typical DPDK examples? > >>>> Sorry. I'm not very familiar with the typical DPDK examples to help u > >>>> here. However this is quite irrelevant since without this this patch > >>>> ixgbe PMD obviously abuses the HW spec as has been explained above. > >>>> > >>>> We saw the issue when u stressed the xmit path with a lot of highly > >>>> fragmented TCP frames (packets with up to 33 fragments with non-headers > >>>> fragments as small as 4 bytes) with all offload features enabled. > > Could you provide us with the pcap file to reproduce the issue? > > Well, the thing is it takes some time to reproduce it (a few minutes of > heavy load) therefore a pcap would be quite large.
Probably you can upload it to some place, from which we will be able to download it? Or might be you have some sort of scapy script to generate it? I suppose we'll need something to reproduce the issue and verify the fix. > > > My concern with you approach is that it would affect TX performance. > > It certainly will ;) But it seem inevitable. See below. > > > Right now, for simple TX PMD usually reads only (nb_tx_desc/tx_rs_thresh) > > TXDs, > > While with your patch (if I understand it correctly) it has to read all > > TXDs in the HW TX ring. > > If by "simple" u refer an always single fragment per Tx packet - then u > are absolutely correct. > > My initial patch was to only set RS on every EOP descriptor without > changing the rs_thresh value and this patch worked. > However HW spec doesn't ensure in a general case that packets are always > handled/completion write-back completes in the same order the packets > are placed on the ring (see "Tx arbitration schemes" chapter in 82599 > spec for instance). Therefore AFAIU one should not assume that if > packet[x+1] DD bit is set then packet[x] is completed too.
