Achiad Shochat 88a85f99e5 net/mlx5e: TX latency optimization to save DMA reads
A regular TX WQE execution involves two or more DMA reads -
one to fetch the WQE, and another one per WQE gather entry.

These DMA reads obviously increase the TX latency.
There are two mlx5 mechanisms to bypass these DMA reads:
1) Inline WQE
2) Blue Flame (BF)

An inline WQE contains a whole packet, thus saves the DMA read/s
of the regular WQE gather entry/s. Inline WQE support was already
added in the previous commit.

A BF WQE is written directly to the device I/O mapped memory, thus
enables saving the DMA read that fetches the WQE.

The BF WQE I/O write must be in cache line granularity, thus uses
the CPU write combining mechanism.
A BF WQE I/O write acts also as a TX doorbell for notifying the
device of new TX WQEs.
A BF WQE is written to the same I/O mapped address as the regular TX
doorbell, thus this address is being mapped twice - once by ioremap()
and once by io_mapping_map_wc().

While both mechanisms reduce the TX latency, they both consume more CPU
cycles than a regular WQE:
- A BF WQE must still be written to host memory, in addition to being
  written directly to the device I/O mapped memory.
- An inline WQE involves copying the SKB data into it.

To handle this tradeoff, we introduce here a heuristic algorithm that
strives to avoid using these two mechanisms in case the TX queue is
being back-pressured by the device, and limit their usage rate otherwise.

An inline WQE will always be "Blue Flamed" (written directly to the
device I/O mapped memory) while a BF WQE may not be inlined (may contain
gather entries).

Preliminary testing using netperf UDP_RR shows that the latency goes down
from 17.5us to 16.9us, while the message rate (tested with pktgen) stays
the same.

Signed-off-by: Achiad Shochat <achiad@mellanox.com>
Signed-off-by: Amir Vadai <amirv@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-07-27 00:29:17 -07:00
..
2015-07-17 16:39:53 -07:00
2015-04-22 09:24:55 -07:00
2015-06-25 11:49:31 +03:00
2015-06-26 14:51:15 -07:00
2015-05-27 12:42:16 -07:00
2015-06-03 14:13:41 +09:00
2015-05-31 13:40:53 +02:00
2015-07-02 11:32:23 -07:00
2015-05-13 12:04:55 -05:00
2015-07-07 22:48:25 +02:00
2015-06-02 08:33:34 -06:00
2015-06-01 14:35:56 -06:00
2015-05-05 13:35:39 -06:00
2015-06-24 17:49:45 -07:00
2015-05-12 10:46:53 +02:00
2015-06-01 14:33:35 +02:00
2015-06-19 15:18:28 +02:00
2015-05-05 13:40:42 -06:00
2015-06-23 18:27:19 -07:00
2015-06-25 12:06:45 +02:00
2015-04-29 17:17:17 -05:00
2015-06-24 17:49:41 -07:00
2015-07-21 10:39:05 -07:00
2015-06-25 04:20:04 -04:00
2015-05-09 22:15:31 -04:00
2015-07-04 14:04:44 -04:00
2015-06-05 10:58:34 -06:00
2015-07-01 19:40:18 -07:00
2015-07-01 19:40:18 -07:00
2015-06-19 01:18:14 +02:00
2015-06-12 11:36:30 +02:00
2015-06-10 19:14:04 +08:00
2015-05-27 12:58:04 -07:00
2015-05-26 15:23:23 +02:00
2015-06-25 01:13:43 +02:00
2015-06-23 18:01:07 -04:00
2015-07-21 10:39:06 -07:00
2015-06-29 10:49:51 -07:00
2015-06-25 17:00:40 -07:00
2015-05-19 09:19:59 -06:00
2015-06-25 17:00:39 -07:00
2015-05-18 14:08:58 -07:00
2015-05-29 17:21:45 -05:00
2015-06-12 17:26:57 -07:00
2015-06-29 11:10:56 -07:00
2015-06-25 17:00:37 -07:00