summaryrefslogtreecommitdiffstats
path: root/arch/um/drivers/vector_kern.h
Commit message (Collapse)AuthorAgeFilesLines
* um: Migrate vector drivers to NAPIAnton Ivanov2022-03-111-1/+2
| | | | | | | | Migrate UML vector drivers from a bespoke scheduling mechanism to NAPI. Signed-off-by: Anton Ivanov <anton.ivanov@cambridgegreys.com> Signed-off-by: Richard Weinberger <richard@nod.at>
* um: virtio: Replace zero-length array with flexible-arrayGustavo A. R. Silva2020-06-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type[1]. There are some instances of code in which the sizeof operator is being incorrectly/erroneously applied to zero-length arrays and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Richard Weinberger <richard@nod.at>
* um: Loadable BPF "Firmware" for vector driversAnton Ivanov2019-11-251-1/+7
| | | | | | | | | | | | | | | | | | | All vector drivers now allow a BPF program to be loaded and associated with the RX socket in the host kernel. 1. The program can be loaded as an extra kernel command line option to any of the vector drivers. 2. The program can also be loaded as "firmware", using the ethtool flash option. It is possible to turn this facility on or off using a command line option. A simplistic wrapper for generating the BPF firmware for the raw socket driver out of a tcpdump/libpcap filter expression can be found at: https://github.com/kot-begemot-uk/uml_vector_utilities/ Signed-off-by: Anton Ivanov <anton.ivanov@cambridgegreys.com> Signed-off-by: Richard Weinberger <richard@nod.at>
* um: Add SPDX headers for files in arch/um/driversAlex Dewar2019-09-151-1/+1
| | | | | | | Convert files to use SPDX header. All files are licensed under the GPLv2. Signed-off-by: Alex Dewar <alex.dewar@gmx.co.uk> Signed-off-by: Richard Weinberger <richard@nod.at>
* um: Error handling fixes in vector driversAnton Ivanov2019-09-151-0/+1
| | | | | | | | | | | | | | | | With the addition of bess support which uses connection oriented SEQPACKET sockets the vector routines can now encounter a "remote end closed the connection" scenario. This adds handling code to detect it in the TX path and the legacy RX path. There is no way to detect it in the vector RX path because that can legitimately return 0 even if the remote end has not closed the connection. As a result the detection is delayed until the first TX event after the close. Signed-off-by: Anton Ivanov <anton.ivanov@cambridgegreys.com> Signed-off-by: Richard Weinberger <richard@nod.at>
* Fix vector raw inintialization logicAnton Ivanov2018-03-291-0/+1
| | | | | | | | | | Vector RAW in UML needs to BPF filter its own MAC only if QDISC_BYPASS has failed. If QDISC_BYPASS is successful, the frames originated locally are not visible to readers on the raw socket. Signed-off-by: Anton Ivanov <anton.ivanov@cambridgegreys.com> Signed-off-by: Richard Weinberger <richard@nod.at>
* High Performance UML Vector Network DriverAnton Ivanov2018-02-191-0/+129
1. Provides infrastructure for vector IO using recvmmsg/sendmmsg. 1.1. Multi-message read. 1.2. Multi-message write. 1.3. Optimized queue support for multi-packet enqueue/dequeue. 1.4. BQL/DQL support. 2. Implements transports for several transports as well support for direct wiring of PWEs to NIC. Allows direct connection of VMs to host, other VMs and network devices with no switch in use. 2.1. Raw socket >4 times higher PPS and 10 times higher tcp RX than existing pcap based transport (> 4Gbit) 2.2. New tap transport using socket RX and tap xmit. Similar performance improvements (>4Gbit) 2.3. GRE transport - direct wiring to GRE PWE 2.4. L2TPv3 transport - direct wiring to L2TPv3 PWE 3. Tuning, performance and offload related setting support via ethtool. 4. Initial BPF support - used in tap/raw to avoid software looping 5. Scatter Gather support. 6. VNET and checksum offload support for raw socket transport. 7. TSO/GSO support where applicable or available 8. Migrates all error messages to netdevice_*() and rate limits them where needed. Signed-off-by: Anton Ivanov <anton.ivanov@cambridgegreys.com> Signed-off-by: Richard Weinberger <richard@nod.at>