From: Vinicius Costa Gomes <vinicius.gomes@intel.com>
To: David Miller <davem@davemloft.net>, rcochran@linutronix.de
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
        intel-wired-lan@lists.osuosl.org, andre.guedes@intel.com,
        anna-maria@linutronix.de, henrik@austad.us,
        jesus.sanchez-palencia@intel.com, john.stultz@linaro.org,
        tglx@linutronix.de
Subject: Re: [PATCH RFC V1 net-next 0/6] Time based packet transmission
In-Reply-To: <20170918.093436.1069699729581966538.davem@davemloft.net>
References: <cover.1505719061.git.rcochran@linutronix.de> <20170918.093436.1069699729581966538.davem@davemloft.net>
User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/25.3.1 (x86_64-pc-linux-gnu)
Date: Tue, 05 Dec 2017 13:22:07 -0800
Message-ID: <87609kj2f4.fsf@intel.com>
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1430
Lines: 46

Hi David,

David Miller <davem@davemloft.net> writes:

> From: Richard Cochran <rcochran@linutronix.de>
> Date: Mon, 18 Sep 2017 09:41:15 +0200
>
>>   - The driver does not handle out of order packets.  If user space
>>     sends a packet with an earlier Tx time, then the code should stop
>>     the queue, reshuffle the descriptors accordingly, and then
>>     restart the queue.
>
> The user should simply be not allowed to do this.
>
> Once the packet is in the device queue, that's it.  You cannot insert
> a new packet to be transmitted before an already hw queued packet,
> period.
>
> Any out of order request should be rejected with an error.

Just to clarify, I agree that after after the packet is enqueued to the
HW, there's no going back, in another words, we must never enqueue
anything to the HW with a timestamp earlier than the last enqueued
packet.

But re-ordering packets at the Qdisc level is, I think, necessary: two
applications (one (A) with period of 50us and the other (B) of 100us),
if it happens that (B) enqueues its packet before (A), I think, we would
have a problem.

The problem is deciding for how long we should keep packets in the Qdisc
queue. In the implementation we are working on, this is left for the
user to decide.

Or do you have a reason for not doing *any* kind of re-ordering?

>
> I'd say the same is true for requests to send packets timed
> in the past.

+1


Cheers,
--
Vinicius