FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=releng%2F14.3 2023-08-16T17:54:36Z 2023-08-16T17:54:36Z Warner Losh imp@FreeBSD.org 2023-08-16T17:54:36Z urn:sha1:685dc743dc3b5645e34836464128e1c0558b404b Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/ 2023-05-12T16:44:03Z Warner Losh imp@FreeBSD.org 2023-05-10T15:40:58Z urn:sha1:4d846d260e2b9a3d4d0a701462568268cbfe7a5b The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch up to that fact and revert to their recommended match of BSD-2-Clause. Discussed with: pfg MFC After: 3 days Sponsored by: Netflix 2023-04-05T16:12:30Z Mark Johnston markj@FreeBSD.org 2023-04-05T16:12:30Z urn:sha1:ce12afaa6fff46c9027eb6b2bd515a4e46ecefc9 In emulated mode, the FreeBSD netmap port attempts to perform zero-copy transmission. This works as follows: the kernel ring is populated with mbuf headers to which netmap buffers are attached. When transmitting, the mbuf refcount is initialized to 2, and when the counter value has been decremented to 1 netmap infers that the driver has freed the mbuf and thus transmission is complete. This scheme does not generalize to the situation where netmap is attaching to a software interface which may transmit packets among multiple "queues", as is the case with bridge or lagg interfaces. In that case, we would be relying on backing hardware drivers to free transmitted mbufs promptly, but this isn't guaranteed; a driver may reasonably defer freeing a small number of transmitted buffers indefinitely. If such a buffer ends up at the tail of a netmap transmit ring, further transmits can end up blocked indefinitely. Fix the problem by removing the zero-copy scheme (which is also not implemented in the Linux port of netmap). Instead, the kernel ring is populated with regular mbuf clusters into which netmap buffers are copied by nm_os_generic_xmit_frame(). The refcounting scheme is preserved, and this lets us avoid allocating a fresh cluster per transmitted packet in the common case. If the transmit ring is full, a callout is used to free the "stuck" mbuf, avoiding the queue deadlock described above. Furthermore, when recycling mbuf clusters, be sure to fully reinitialize the mbuf header instead of simply re-setting M_PKTHDR. Some software interfaces, like if_vlan, may set fields in the header which should be reset before the mbuf is reused. Reviewed by: vmaffione MFC after: 1 month Sponsored by: Zenarmor Sponsored by: OPNsense Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D38065 2023-03-11T17:19:40Z Vincenzo Maffione vmaffione@FreeBSD.org 2023-03-11T17:19:01Z urn:sha1:22bf2a479f68d5a5b8c002a9103d95f3c7547067 MFC after: 7 days 2023-02-14T15:21:19Z Justin Hibbits jhibbits@FreeBSD.org 2023-01-12T18:38:37Z urn:sha1:e330262f34fc179ce920c16bb28ba8a1c4a73aff Reviewed by: vmaffione, zlei Sponsored by: Juniper Networks, Inc. Differential Revision: https://reviews.freebsd.org/D37814 2023-01-23T19:42:41Z Mark Johnston markj@FreeBSD.org 2023-01-23T19:42:41Z urn:sha1:df40e30c9786ccbf51e3acdf936d5c0e20815652 Right now we have little visibility into packet drops within netmap. Start trying to make packet loss issues more visible by counting queue drops in the transmit path, and in the input path for interfaces running in emulated mode, where we place received packets in a bounded software queue that is processed by rxsync. Reviewed by: vmaffione MFC after: 1 week Sponsored by: Zenarmor Sponsored by: OPNsense Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D38064 2023-01-23T19:41:55Z Mark Johnston markj@FreeBSD.org 2023-01-23T19:41:55Z urn:sha1:539437c8281d24450bacded3734276acd9983e90 The check is ok by default, since the default value of netmap_generic_ringsize is 1024. But we should check against the configured "ring" size. Reviewed by: vmaffione MFC after: 1 week Sponsored by: Zenarmor Sponsored by: OPNsense Sponsored by: Klara, Inc. Differential Revision: https://reviews.freebsd.org/D38062 2022-12-24T14:36:31Z Vincenzo Maffione vmaffione@FreeBSD.org 2022-12-24T14:31:14Z urn:sha1:3da494d3246e30a19d2107c8bb8a293ffd5a9da6 Netmap users on FreeBSD are not supposed to import code from the github netmap repository anymore. They should use the code that is available in the src repo. We can therefore drop the compatibility code. MFC after: 7 days 2021-04-02T07:01:20Z Vincenzo Maffione vmaffione@FreeBSD.org 2021-04-02T07:01:20Z urn:sha1:45c67e8f6b56b9744f01142747fadf291fe3fad2 No functional changes intended. 2021-03-29T16:29:01Z Vincenzo Maffione vmaffione@FreeBSD.org 2021-03-29T16:22:48Z urn:sha1:a6d768d845c173823785c71bb18b40074e7a8998 This feature enables applications to ask netmap to transmit or receive packets starting at a user-specified offset from the beginning of the netmap buffer. This is meant to ease those packet manipulation operations such as pushing or popping packet headers, that may be useful to implement software switches, routers and other packet processors. To use the feature, drivers (e.g., iflib, vtnet, etc.) must have explicit support. This change does not add support for any driver, but introduces the necessary kernel changes. However, offsets support is already included for VALE ports and pipes.