On do, 25 apr 2019 17:53:39 +0200, Oleksij Rempel wrote: > On Thu, Apr 25, 2019 at 05:45:03PM +0200, Marc Kleine-Budde wrote: > > On 4/25/19 5:39 PM, David Jander wrote: > > > 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? 2 and a little 4. > > >>> > > >>> 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. > > > > We haven't looked at the RX path at all. For now the kernel receives the > > whole ETP and then pushes the whole block to any matching socket. > > Status update can be done for both directions. For the RX path we should > implement session to socket binding first. > > How this functionality should be enabled? Per socket or per packet? > Should it be enabled separately for TX and RX? > RX will be possible only per socket. TX can be done both. I think you ideally configure it per PGN and per socket, any direction. if a PGN is sent/recvd smaller than a TP sized block, no report at all, so only reports if it's bigger. > > > > I agree that we should implement that later and leave it as a TODO now. > > > > OK, maybe we could add some kind of public TODO list for this.
