Re: [PATCH net-next 4/5] tsnep: Add TSN endpoint Ethernet MAC driver

[Gerhard Engleder <gerhard@engleder-embedded.com>]

> > This driver provides a driver specific interface in tsnep_stream.c for
> > direct access to all but the first TX/RX queue pair. There are two
> > reasons for this interface. First: It enables the reservation or direct use
> > of TX/RX queue pairs by real-time application on dedicated CPU cores or
> > in user space.
>
> Hi Gerhard

Hi Andrew,

> I expect you will get a lot of push back with a character device in
> the middle of an Ethernet driver. One that mmap the Tx/Rx queue is
> going to need a lot of review to make sure it is secure. Maybe talk to
> the XDP/AF_XDP people, there might be a way to do it through that?

I also expect some discussion about this feature. Mapping device specific
TX/RX queues to user space is not done in mainline Linux so far. It is done
out-of-tree for real-time communication since years. It enables interrupt free
(hard and soft IRQ) zero copy communication without any context switch
between kernel space and user space. This is ideal for real-time. It is similar
to UIO, but with DMA support and only for some TX/RX queues and not for
the whole device.

If the mmap of TX/RX queue can be done by any user space program, then
it might not be secure. The mmap of TX/RX queue will be done by the
real-time application and the real-time application needs to be privileged
anyway (SCHED_FIFO, mlock, ...). So for the real-time use case I don't see
any security problem.

There are some reasons for not using XDP/AF_XDP:
- XDP/AF_XDP does not support timed transmission and this device has
  a very special style of timed transmission (schedule with relative timings
  for DMA start and transmit time within descriptor ring, the relative timings
  define the timing of the _next_ descriptor/frame)
- XDP/AF_XDP requires Linux and the additional TX/RX Queues of this
  device are designed to be used also by other CPU cores which do not run
  Linux
- XDP/AF_XDP needs hard and/or soft IRQ processing

> So i strongly suggest your drop tsnep_stream.c for the moment. Get the
> basic plain boring Ethernet driver merged. Then start a discussion
> about a suitable API for exporting rings to user space.

I will follow your suggestion and drop tsnep_stream.c for the moment.
Any early comments about this feature are welcome, because the direct
use of additional TX/RX queues for real-time communication is the main
feature of this device.

Gerhard