FreeBSD source tree http://cgit.freebsd.org/src/atom?h=releng%2F15.0 2024-03-26T09:55:55Z 2024-03-26T09:55:55Z Tom Jones thj@FreeBSD.org 2024-03-26T09:52:07Z urn:sha1:73fdbfb911215795c55c89870ebc5d9197bf2a23 netmap_generic keeps a pool of mbufs for handling transfers, these mbufs have an external buffer attached to them. If some cases other parts of the network stack can chain these mbufs, when this happens the normal pool destructor function can end up free'ing the pool mbufs twice: - A first time if a pool mbuf has been chained with another mbuf when its chain is freed - A second time when its entry in the pool is freed Additionally, if other parts of the stack demote a pool mbuf its interface reference will be cleared. In this case we deference a NULL pointer when trying to free the mbuf through the destructor. Store a reference to the adapter in ext_arg1 with the destructor callback so we can find the correct adapter when free'ing a pool mbuf. This change enables using netmap with epair interfaces. Reviewed By: vmaffione MFC after: 1 week Relnotes: yes Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D44371 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.