> > 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
