On 11/10/2016 1:22 AM, Leon Romanovsky wrote:
On Wed, Nov 09, 2016 at 05:06:52PM +0000, Hefty, Sean wrote:
On Tue, Nov 08, 2016 at 05:49:26PM +0000, Hefty, Sean wrote:
When sending from a 10G host to a 1G host, it is easy to overrun
the
receiver,
leading to packet loss and traffic backing off. Similar problems
occur
when
a 10G host sends data to a sub-10G virtual circuit, or a 40G host
sending
to a 10G host. Packet pacing could control packet injection rate
and
reduces
network congestion to maximize throughput & minimize network
latency.
Why isn't the path record data and existing mechanisms sufficient to
handle this?
Packet pacing allows different combinations of traffic shaping: per-
CPU,
per-flow and their combinations with better and steady QoS requirements
without involving subnet management.
The patch adds this as a QP attribute, and we already have a rate for that. I still don't see why the standard mechanisms are insufficient or couldn't be adapted.
I'll let to Bodong to elaborate on it more, but as far as I see, the AH
attribute is relevant to UD QP only, while the packet pacing is intended
for all types of QPs.
Thanks
While the path record data can prevent the overrun but cannot control
the rate speed easily within the hardware limitation range. One main use
case for packet pacing is for streaming vendors to control the speed for
different customers based on service coverage. For example, user's NIC
supports 10G speed but only pays for 1G speed service, packet pacing can
achieve this purpose only by modify_qp.
Another advantage, packet pacing doesn't need to involve with subnet
admin which path record data has to. Moreover, like indicated in the
other thread, the main flaw of the static rate is its limitations on the
speed options.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
