#
b977dd1e |
|
29-Mar-2024 |
Gleb Smirnoff <glebius@FreeBSD.org> |
linux: make linux_netlink_p->msg_from_linux be able to fail The KPI for this function was misleading. From the NetLink perspective it looked like a function that: a) allocates new hdr, b) can fail. Neither was true. Let the function return a error code instead of returning the same hdr it was passed to. In case if future Linux NetLink compatibility support calls for reallocating header, pass hdr as pointer to pointer. With KPI that returns a error, propagate domain conversion errors all the way up to NetLink module. This fixes panic when unknown domain is converted to 0xff and this invalid value is passed into NetLink processing. PR: 274536 Reviewed by: melifaro Differential Revision: https://reviews.freebsd.org/D44392
|
#
17083b94 |
|
02-Jan-2024 |
Gleb Smirnoff <glebius@FreeBSD.org> |
netlink: use protocol specific receive buffer Implement Netlink socket receive buffer as a simple TAILQ of nl_buf's, same part of struct sockbuf that is used for send buffer already. This shaves a lot of code and a lot of extra processing. The pcb rids of the I/O queues as the socket buffer is exactly the queue. The message writer is simplified a lot, as we now always deal with linear buf. Notion of different buffer types goes away as way as different kinds of writers. The only things remaining are: a socket writer and a group writer. The impact on the network stack is that we no longer use mbufs, so a workaround from d18715475071 disappears. Note on message throttling. Now the taskqueue throttling mechanism needs to look at both socket buffers protected by their respective locks and on flags in the pcb that are protected by the pcb lock. There is definitely some room for optimization, but this changes tries to preserve as much as possible. Note on new nl_soreceive(). It emulates soreceive_generic(). It must undergo further optimization, see large comment put in there. Note on tests/sys/netlink/test_netlink_message_writer.py. This test boiled down almost to nothing with mbufs removed. However, I left it with minimal functionality (it basically checks that allocating N bytes we get N bytes) as it is one of not so many examples of ktest framework that allows to test KPIs with python. Note on Linux support. It got much simplier: Netlink message writer loses notion of Linux support lifetime, it is same regardless of process ABI. On socket write from Linux process we perform conversion immediately in nl_receive_message() and on an output conversion to Linux happens in in nl_send_one(). XXX: both conversions use M_NOWAIT allocation, which used to be the case before this change, too. Reviewed by: melifaro Differential Revision: https://reviews.freebsd.org/D42524
|
#
7e5bf684 |
|
20-Jan-2022 |
Alexander V. Chernikov <melifaro@FreeBSD.org> |
netlink: add netlink support Netlinks is a communication protocol currently used in Linux kernel to modify, read and subscribe for nearly all networking state. Interfaces, addresses, routes, firewall, fibs, vnets, etc are controlled via netlink. It is async, TLV-based protocol, providing 1-1 and 1-many communications. The current implementation supports the subset of NETLINK_ROUTE family. To be more specific, the following is supported: * Dumps: - routes - nexthops / nexthop groups - interfaces - interface addresses - neighbors (arp/ndp) * Notifications: - interface arrival/departure - interface address arrival/departure - route addition/deletion * Modifications: - adding/deleting routes - adding/deleting nexthops/nexthops groups - adding/deleting neghbors - adding/deleting interfaces (basic support only) * Rtsock interaction - route events are bridged both ways The implementation also supports the NETLINK_GENERIC family framework. Implementation notes: Netlink is implemented via loadable/unloadable kernel module, not touching many kernel parts. Each netlink socket uses dedicated taskqueue to support async operations that can sleep, such as interface creation. All message processing is performed within these taskqueues. Compatibility: Most of the Netlink data models specified above maps to FreeBSD concepts nicely. Unmodified ip(8) binary correctly works with interfaces, addresses, routes, nexthops and nexthop groups. Some software such as net/bird require header-only modifications to compile and work with FreeBSD netlink. Reviewed by: imp Differential Revision: https://reviews.freebsd.org/D36002 MFC after: 2 months
|