From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Ma Subject: Re: Per-CPU Queueing for QoS Date: Sun, 12 Nov 2017 13:43:13 -0800 Message-ID: References: Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: jianjun.duan@alibaba-inc.com, xiangning.yu@alibaba-inc.com To: Linux Kernel Network Developers Return-path: Received: from mail-pf0-f175.google.com ([209.85.192.175]:44859 "EHLO mail-pf0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750921AbdKLVnT (ORCPT ); Sun, 12 Nov 2017 16:43:19 -0500 Received: by mail-pf0-f175.google.com with SMTP id x7so10466564pfa.1 for ; Sun, 12 Nov 2017 13:43:19 -0800 (PST) In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: Any comments? We plan to implement this as a qdisc and appreciate any early f= eedback. Thanks, Michael > On Nov 9, 2017, at 5:20 PM, Michael Ma wrote: >=20 > Currently txq/qdisc selection is based on flow hash so packets from > the same flow will follow the order when they enter qdisc/txq, which > avoids out-of-order problem. >=20 > To improve the concurrency of QoS algorithm we plan to have multiple > per-cpu queues for a single TC class and do busy polling from a > per-class thread to drain these queues. If we can do this frequently > enough the out-of-order situation in this polling thread should not be > that bad. >=20 > To give more details - in the send path we introduce per-cpu per-class > queues so that packets from the same class and same core will be > enqueued to the same place. Then a per-class thread poll the queues > belonging to its class from all the cpus and aggregate them into > another per-class queue. This can effectively reduce contention but > inevitably introduces potential out-of-order issue. >=20 > Any concern/suggestion for working towards this direction?