On Thu, 25 Apr 2019 17:27:13 +0200 Marc Kleine-Budde <mkl@xxxxxxxxxxxxxx> wrote: > On 4/25/19 5:12 PM, Oleksij Rempel wrote: > > On Thu, Apr 25, 2019 at 02:54:16PM +0200, Kurt Van Dijck wrote: > >> On do, 25 apr 2019 14:31:06 +0200, Oleksij Rempel wrote: > >>> Hi all, > >>> > >>> please take a look at this patches. It is UAPI extension and it is good to > >>> know if it is sane way to track/recognize send packages. > >> > >> (1) This feedback reports success or failure for packets. > >> That is usefull at some point. > >> Is there a mechanism to track the real progress. This is something I had > >> in /proc somewhere, and which is usefull for larger transfers ... > > > > It can be done in the same way over error queue. The question is, what is the use case? > > 1. debugging? > > 2. provide progress bar for the GUI? > > 3. optimization? > > 4. coordination with some kind of watchdog? > > > > For example we can send notification for each transferred TP sized block of ETP > > transfer and make it configurable per setsocketopt. > > If this is of general interest, we could make a TODO item from this. > That could be implemented later. Providing a progress bar is something I can think of quite desirable. Some sort of notification for each TP sized block might be good enough for that purpose. But, I assume this will only work for TX and not for RX, right? The notion of a progress bar for incoming data on an ETP session is also something quite useful for an application. I agree that we should implement that later and leave it as a TODO now. > >> (2) The way I see your patch, it publishes something into an error queue. > >> does the err queue require emptying? what happens if you don't read the err queue? > > > > Yes, the sk_error_queue require dequeuing or purging. I will need to add > > setsockopt to enable/disable sk_error_queue. It will be disabled by default. > > How does this work on other protocols? Good question... Best regards, -- David Jander Protonic Holland.
