From: Ioana Ciocoi Radulescu <ruxandra.radule...@nxp.com> Date: Wed, 7 Nov 2018 10:31:16 +0000
> We chose this mechanism over BQL (to which it is conceptually > very similar) because a) we can take advantage of the hardware > offloading and b) BQL doesn't match well with our driver fastpath > (we process ingress (Rx or Tx conf) frames in batches of up to 16, > which in certain scenarios confuses the BQL adaptive algorithm, > resulting in too low values of the limit and low performance). First, this kind of explanation belongs in the commit message. Second, you'll have to describe better what BQL, which is the ultimate standard mechanism for every single driver in the kernel to deal with this issue. Are you saying that if 15 TX frames are pending, not TX interrupt will arrive at all? There absolutely must be some timeout or similar interrupt that gets sent in that kind of situation. You cannot leave stale TX packets on your ring unprocessed just because a non-multiple of 16 packets were queued up and then TX activity stopped.
