#
76c8764e |
| 27-Mar-2024 |
Wojciech Drewek <wojciech.drewek@intel.com> |
pfcp: add PFCP module
Packet Forwarding Control Protocol (PFCP) is a 3GPP Protocol used between the control plane and the user plane function. It is specified in TS 29.244[1].
Note that this module
pfcp: add PFCP module
Packet Forwarding Control Protocol (PFCP) is a 3GPP Protocol used between the control plane and the user plane function. It is specified in TS 29.244[1].
Note that this module is not designed to support this Protocol in the kernel space. There is no support for parsing any PFCP messages. There is no API that could be used by any userspace daemon. Basically it does not support PFCP. This protocol is sophisticated and there is no need for implementing it in the kernel. The purpose of this module is to allow users to setup software and hardware offload of PFCP packets using tc tool.
When user requests to create a PFCP device, a new socket is created. The socket is set up with port number 8805 which is specific for PFCP [29.244 4.2.2]. This allow to receive PFCP request messages, response messages use other ports.
Note that only one PFCP netdev can be created.
Only IPv4 is supported at this time.
[1] https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3111
Signed-off-by: Wojciech Drewek <wojciech.drewek@intel.com> Signed-off-by: Marcin Szycik <marcin.szycik@linux.intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Alexander Lobakin <aleksander.lobakin@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
35dfaad7 |
| 24-Oct-2023 |
Daniel Borkmann <daniel@iogearbox.net> |
netkit, bpf: Add bpf programmable net device
This work adds a new, minimal BPF-programmable device called "netkit" (former PoC code-name "meta") we recently presented at LSF/MM/BPF. The core idea is
netkit, bpf: Add bpf programmable net device
This work adds a new, minimal BPF-programmable device called "netkit" (former PoC code-name "meta") we recently presented at LSF/MM/BPF. The core idea is that BPF programs are executed within the drivers xmit routine and therefore e.g. in case of containers/Pods moving BPF processing closer to the source.
One of the goals was that in case of Pod egress traffic, this allows to move BPF programs from hostns tcx ingress into the device itself, providing earlier drop or forward mechanisms, for example, if the BPF program determines that the skb must be sent out of the node, then a redirect to the physical device can take place directly without going through per-CPU backlog queue. This helps to shift processing for such traffic from softirq to process context, leading to better scheduling decisions/performance (see measurements in the slides).
In this initial version, the netkit device ships as a pair, but we plan to extend this further so it can also operate in single device mode. The pair comes with a primary and a peer device. Only the primary device, typically residing in hostns, can manage BPF programs for itself and its peer. The peer device is designated for containers/Pods and cannot attach/detach BPF programs. Upon the device creation, the user can set the default policy to 'pass' or 'drop' for the case when no BPF program is attached.
Additionally, the device can be operated in L3 (default) or L2 mode. The management of BPF programs is done via bpf_mprog, so that multi-attach is supported right from the beginning with similar API and dependency controls as tcx. For details on the latter see commit 053c8e1f235d ("bpf: Add generic attach/detach/query API for multi-progs"). tc BPF compatibility is provided, so that existing programs can be easily migrated.
Going forward, we plan to use netkit devices in Cilium as the main device type for connecting Pods. They will be operated in L3 mode in order to simplify a Pod's neighbor management and the peer will operate in default drop mode, so that no traffic is leaving between the time when a Pod is brought up by the CNI plugin and programs attached by the agent. Additionally, the programs we attach via tcx on the physical devices are using bpf_redirect_peer() for inbound traffic into netkit device, hence the latter is also supporting the ndo_get_peer_dev callback. Similarly, we use bpf_redirect_neigh() for the way out, pushing from netkit peer to phys device directly. Also, BIG TCP is supported on netkit device. For the follow-up work in single device mode, we plan to convert Cilium's cilium_host/_net devices into a single one.
An extensive test suite for checking device operations and the BPF program and link management API comes as BPF selftests in this series.
Co-developed-by: Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com> Acked-by: Stanislav Fomichev <sdf@google.com> Acked-by: Martin KaFai Lau <martin.lau@kernel.org> Link: https://github.com/borkmann/iproute2/tree/pr/netkit Link: http://vger.kernel.org/bpfconf2023_material/tcx_meta_netdev_borkmann.pdf (24ff.) Link: https://lore.kernel.org/r/20231024214904.29825-2-daniel@iogearbox.net Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
show more ...
|
#
1dab4713 |
| 09-Oct-2023 |
Arnd Bergmann <arnd@arndb.de> |
appletalk: remove ipddp driver
After the cops driver is removed, ipddp is now the only CONFIG_DEV_APPLETALK but as far as I can tell, this also has no users and can be removed, making appletalk supp
appletalk: remove ipddp driver
After the cops driver is removed, ipddp is now the only CONFIG_DEV_APPLETALK but as far as I can tell, this also has no users and can be removed, making appletalk support purely based on ethertalk, using ethernet hardware.
Link: https://lore.kernel.org/netdev/e490dd0c-a65d-4acf-89c6-c06cb48ec880@app.fastmail.com/ Link: https://lore.kernel.org/netdev/9cac4fbd-9557-b0b8-54fa-93f0290a6fb8@schmorgal.com/ Cc: Doug Brown <doug@schmorgal.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20231009141139.1766345-1-arnd@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
0d0950a9 |
| 11-Jan-2023 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
net: thunderbolt: Move into own directory
We will be adding tracepoints to the driver so instead of littering the main network driver directory, move the driver into its own directory. While there,
net: thunderbolt: Move into own directory
We will be adding tracepoints to the driver so instead of littering the main network driver directory, move the driver into its own directory. While there, rename the module to thunderbolt_net (with underscore) to match with the thunderbolt_dma_test convention.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Yehezkel Bernat <YehezkelShB@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
3114b075 |
| 03-Oct-2022 |
Oleksij Rempel <o.rempel@pengutronix.de> |
net: add framework to support Ethernet PSE and PDs devices
This framework was create with intention to provide support for Ethernet PSE (Power Sourcing Equipment) and PDs (Powered Device).
At curre
net: add framework to support Ethernet PSE and PDs devices
This framework was create with intention to provide support for Ethernet PSE (Power Sourcing Equipment) and PDs (Powered Device).
At current step this patch implements generic PSE support for PoDL (Power over Data Lines 802.3bu) specification with reserving name space for PD devices as well.
This framework can be extended to support 802.3af and 802.3at "Power via the Media Dependent Interface" (or PoE/Power over Ethernet)
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
67653936 |
| 01-Mar-2022 |
Roopa Prabhu <roopa@nvidia.com> |
vxlan: move to its own directory
vxlan.c has grown too long. This patch moves it to its own directory. subsequent patches add new functionality in new files.
Signed-off-by: Roopa Prabhu <roopa@nvid
vxlan: move to its own directory
vxlan.c has grown too long. This patch moves it to its own directory. subsequent patches add new functionality in new files.
Signed-off-by: Roopa Prabhu <roopa@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
b9022b53 |
| 31-Oct-2021 |
Taehee Yoo <ap420073@gmail.com> |
amt: add control plane of amt interface
It adds definitions and control plane code for AMT. this is very similar to udp tunneling interfaces such as gtp, vxlan, etc. In the next patch, data plane co
amt: add control plane of amt interface
It adds definitions and control plane code for AMT. this is very similar to udp tunneling interfaces such as gtp, vxlan, etc. In the next patch, data plane code will be added.
Signed-off-by: Taehee Yoo <ap420073@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
7ffa7542 |
| 03-Aug-2021 |
Loic Poulain <loic.poulain@linaro.org> |
net: mhi: Remove MBIM protocol
The MBIM protocol has now been integrated in a proper WWAN driver. We can then revert back to a simpler driver for mhi_net, which is used for raw IP or QMAP protocol (
net: mhi: Remove MBIM protocol
The MBIM protocol has now been integrated in a proper WWAN driver. We can then revert back to a simpler driver for mhi_net, which is used for raw IP or QMAP protocol (via rmnet link).
- Remove protocol management - Remove WWAN framework usage (only valid for mbim) - Remove net/mhi directory for simpler mhi_net.c file
Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
4228c394 |
| 03-Aug-2021 |
Arnd Bergmann <arnd@arndb.de> |
make legacy ISA probe optional
There are very few ISA drivers left that rely on the static probing from drivers/net/Space.o. Make them all select a new CONFIG_NETDEV_LEGACY_INIT symbol, and drop the
make legacy ISA probe optional
There are very few ISA drivers left that rely on the static probing from drivers/net/Space.o. Make them all select a new CONFIG_NETDEV_LEGACY_INIT symbol, and drop the entire probe logic when that is disabled.
The 9 drivers that are called from Space.c are the same set that calls netdev_boot_setup_check().
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
4b2e6930 |
| 29-Jul-2021 |
Jeremy Kerr <jk@codeconstruct.com.au> |
mctp: Add initial driver infrastructure
Add an empty drivers/net/mctp/, for future interface drivers.
Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Signed-off-by: David S. Miller <davem@dave
mctp: Add initial driver infrastructure
Add an empty drivers/net/mctp/, for future interface drivers.
Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
9a44c1cc |
| 16-Apr-2021 |
Loic Poulain <loic.poulain@linaro.org> |
net: Add a WWAN subsystem
This change introduces initial support for a WWAN framework. Given the complexity and heterogeneity of existing WWAN hardwares and interfaces, there is no strict definition
net: Add a WWAN subsystem
This change introduces initial support for a WWAN framework. Given the complexity and heterogeneity of existing WWAN hardwares and interfaces, there is no strict definition of what a WWAN device is and how it should be represented. It's often a collection of multiple devices that perform the global WWAN feature (netdev, tty, chardev, etc).
One usual way to expose modem controls and configuration is via high level protocols such as the well known AT command protocol, MBIM or QMI. The USB modems started to expose them as character devices, and user daemons such as ModemManager learnt to use them.
This initial version adds the concept of WWAN port, which is a logical pipe to a modem control protocol. The protocols are rawly exposed to user via character device, allowing straigthforward support in existing tools (ModemManager, ofono...). The WWAN core takes care of the generic part, including character device management, and relies on port driver operations to receive/submit protocol data.
Since the different devices exposing protocols for a same WWAN hardware do not necessarily know about each others (e.g. two different USB interfaces, PCI/MHI channel devices...) and can be created/removed in different orders, the WWAN core ensures that all WAN ports contributing to the 'whole' WWAN feature are grouped under the same virtual WWAN device, relying on the provided parent device (e.g. mhi controller, USB device). It's a 'trick' I copied from Johannes's earlier WWAN subsystem proposal.
This initial version is purposely minimalist, it's essentially moving the generic part of the previously proposed mhi_wwan_ctrl driver inside a common WWAN framework, but the implementation is open and flexible enough to allow extension for further drivers.
Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
227d7206 |
| 19-Mar-2021 |
Alexander Lobakin <alobakin@pm.me> |
dsa: simplify Kconfig symbols and dependencies
1. Remove CONFIG_HAVE_NET_DSA.
CONFIG_HAVE_NET_DSA is a legacy leftover from the times when drivers should have selected CONFIG_NET_DSA manually. Curr
dsa: simplify Kconfig symbols and dependencies
1. Remove CONFIG_HAVE_NET_DSA.
CONFIG_HAVE_NET_DSA is a legacy leftover from the times when drivers should have selected CONFIG_NET_DSA manually. Currently, all drivers has explicit 'depends on NET_DSA', so this is no more needed.
2. CONFIG_HAVE_NET_DSA dependencies became CONFIG_NET_DSA's ones.
- dropped !S390 dependency which was introduced to be sure NET_DSA can select CONFIG_PHYLIB. DSA migrated to Phylink almost 3 years ago and the PHY library itself doesn't depend on !S390 since commit 870a2b5e4fcd ("phylib: remove !S390 dependeny from Kconfig"); - INET dependency is kept to be sure we can select NET_SWITCHDEV; - NETDEVICES dependency is kept to be sure we can select PHYLINK.
3. DSA drivers menu now depends on NET_DSA.
Instead on 'depends on NET_DSA' on every single driver, the entire menu now depends on it. This eliminates a lot of duplicated lines from Kconfig with no loss (when CONFIG_NET_DSA=m, drivers also can be only m or n). This also has a nice side effect that there's no more empty menu on configurations without DSA.
4. Kbuild will now descend into 'drivers/net/dsa' only when CONFIG_NET_DSA is y or m.
This is safe since no objects inside this folder can be built without DSA core, as well as when CONFIG_NET_DSA=m, no objects can be built-in.
Signed-off-by: Alexander Lobakin <alobakin@pm.me> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
b6ec6b89 |
| 09-Feb-2021 |
Loic Poulain <loic.poulain@linaro.org> |
net: mhi: Add dedicated folder
Create a dedicated mhi directory for mhi-net, mhi-net is going to be split into differente files (for additional protocol support).
Signed-off-by: Loic Poulain <loic.
net: mhi: Add dedicated folder
Create a dedicated mhi directory for mhi-net, mhi-net is going to be split into differente files (for additional protocol support).
Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
3ffec6a1 |
| 03-Nov-2020 |
Loic Poulain <loic.poulain@linaro.org> |
net: Add mhi-net driver
This patch adds a new network driver implementing MHI transport for network packets. Packets can be in any format, though QMAP (rmnet) is the usual protocol (flow control + P
net: Add mhi-net driver
This patch adds a new network driver implementing MHI transport for network packets. Packets can be in any format, though QMAP (rmnet) is the usual protocol (flow control + PDN mux).
It support two MHI devices, IP_HW0 which is, the path to the IPA (IP accelerator) on qcom modem, And IP_SW0 which is the software driven IP path (to modem CPU).
Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/1604424234-24446-2-git-send-email-loic.poulain@linaro.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
show more ...
|
#
f54ec58f |
| 27-Oct-2020 |
Arnd Bergmann <arnd@arndb.de> |
wimax: move out to staging
There are no known users of this driver as of October 2020, and it will be removed unless someone turns out to still need it in future releases.
According to https://en.w
wimax: move out to staging
There are no known users of this driver as of October 2020, and it will be removed unless someone turns out to still need it in future releases.
According to https://en.wikipedia.org/wiki/List_of_WiMAX_networks, there have been many public wimax networks, but it appears that many of these have migrated to LTE or discontinued their service altogether. As most PCs and phones lack WiMAX hardware support, the remaining networks tend to use standalone routers. These almost certainly run Linux, but not a modern kernel or the mainline wimax driver stack.
NetworkManager appears to have dropped userspace support in 2015 https://bugzilla.gnome.org/show_bug.cgi?id=747846, the www.linuxwimax.org site had already shut down earlier.
WiMax is apparently still being deployed on airport campus networks ("AeroMACS"), but in a frequency band that was not supported by the old Intel 2400m (used in Sandy Bridge laptops and earlier), which is the only driver using the kernel's wimax stack.
Move all files into drivers/staging/wimax, including the uapi header files and documentation, to make it easier to remove it when it gets to that. Only minimal changes are made to the source files, in order to make it possible to port patches across the move.
Also remove the MAINTAINERS entry that refers to a broken mailing list and website.
Acked-by: Jakub Kicinski <kuba@kernel.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-By: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com> Acked-by: Johannes Berg <johannes@sipsolutions.net> Suggested-by: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
show more ...
|
#
a9770eac |
| 27-Aug-2020 |
Andrew Lunn <andrew@lunn.ch> |
net: mdio: Move MDIO drivers into a new subdirectory
Move all the MDIO drivers and multiplexers into drivers/net/mdio. The mdio core is however left in the phy directory, due to mutual dependencies
net: mdio: Move MDIO drivers into a new subdirectory
Move all the MDIO drivers and multiplexers into drivers/net/mdio. The mdio core is however left in the phy directory, due to mutual dependencies between the MDIO core and the PHY core.
Take this opportunity to sort the Kconfig based on the menuconfig strings, and move the multiplexers to the end with a separating comment.
v2: Fix typo in commit message
Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
2fa4e4b7 |
| 27-Aug-2020 |
Andrew Lunn <andrew@lunn.ch> |
net: pcs: Move XPCS into new PCS subdirectory
Create drivers/net/pcs and move the Synopsys DesignWare XPCS into the new directory. Move the header file into a subdirectory include/linux/pcs
Start a
net: pcs: Move XPCS into new PCS subdirectory
Create drivers/net/pcs and move the Synopsys DesignWare XPCS into the new directory. Move the header file into a subdirectory include/linux/pcs
Start a naming convention of all PCS files use the prefix pcs-, and rename the XPCS files to fit.
v2: Add include/linux/pcs
v4: Fix include path in stmmac. Remove PCS_DEVICES to avoid new prompts
Cc: Jose Abreu <Jose.Abreu@synopsys.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
08120d23 |
| 06-Mar-2020 |
Alex Elder <elder@linaro.org> |
soc: qcom: ipa: support build of IPA code
Add build and Kconfig support for the Qualcomm IPA driver.
Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
|
#
571912c6 |
| 24-Feb-2020 |
Martin Varghese <martin.varghese@nokia.com> |
net: UDP tunnel encapsulation module for tunnelling different protocols like MPLS, IP, NSH etc.
The Bareudp tunnel module provides a generic L3 encapsulation tunnelling module for tunnelling differe
net: UDP tunnel encapsulation module for tunnelling different protocols like MPLS, IP, NSH etc.
The Bareudp tunnel module provides a generic L3 encapsulation tunnelling module for tunnelling different protocols like MPLS, IP,NSH etc inside a UDP tunnel.
Signed-off-by: Martin Varghese <martin.varghese@nokia.com> Acked-by: Willem de Bruijn <willemb@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
690ac0d2 |
| 17-Dec-2019 |
Mika Westerberg <mika.westerberg@linux.intel.com> |
thunderbolt: Update Kconfig entries to USB4
Since the driver now supports USB4 which is the standard going forward, update the Kconfig entry to mention this and rename the entry from CONFIG_THUNDERB
thunderbolt: Update Kconfig entries to USB4
Since the driver now supports USB4 which is the standard going forward, update the Kconfig entry to mention this and rename the entry from CONFIG_THUNDERBOLT to CONFIG_USB4 instead to help people to find the correct option if they want to enable USB4.
Also do the same for Thunderbolt network driver.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: David S. Miller <davem@davemloft.net> Link: https://lore.kernel.org/r/20191217123345.31850-6-mika.westerberg@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
e7096c13 |
| 08-Dec-2019 |
Jason A. Donenfeld <Jason@zx2c4.com> |
net: WireGuard secure network tunnel
WireGuard is a layer 3 secure networking tunnel made specifically for the kernel, that aims to be much simpler and easier to audit than IPsec. Extensive document
net: WireGuard secure network tunnel
WireGuard is a layer 3 secure networking tunnel made specifically for the kernel, that aims to be much simpler and easier to audit than IPsec. Extensive documentation and description of the protocol and considerations, along with formal proofs of the cryptography, are available at:
* https://www.wireguard.com/ * https://www.wireguard.com/papers/wireguard.pdf
This commit implements WireGuard as a simple network device driver, accessible in the usual RTNL way used by virtual network drivers. It makes use of the udp_tunnel APIs, GRO, GSO, NAPI, and the usual set of networking subsystem APIs. It has a somewhat novel multicore queueing system designed for maximum throughput and minimal latency of encryption operations, but it is implemented modestly using workqueues and NAPI. Configuration is done via generic Netlink, and following a review from the Netlink maintainer a year ago, several high profile userspace tools have already implemented the API.
This commit also comes with several different tests, both in-kernel tests and out-of-kernel tests based on network namespaces, taking profit of the fact that sockets used by WireGuard intentionally stay in the namespace the WireGuard interface was originally created, exactly like the semantics of userspace tun devices. See wireguard.com/netns/ for pictures and examples.
The source code is fairly short, but rather than combining everything into a single file, WireGuard is developed as cleanly separable files, making auditing and comprehension easier. Things are laid out as follows:
* noise.[ch], cookie.[ch], messages.h: These implement the bulk of the cryptographic aspects of the protocol, and are mostly data-only in nature, taking in buffers of bytes and spitting out buffers of bytes. They also handle reference counting for their various shared pieces of data, like keys and key lists.
* ratelimiter.[ch]: Used as an integral part of cookie.[ch] for ratelimiting certain types of cryptographic operations in accordance with particular WireGuard semantics.
* allowedips.[ch], peerlookup.[ch]: The main lookup structures of WireGuard, the former being trie-like with particular semantics, an integral part of the design of the protocol, and the latter just being nice helper functions around the various hashtables we use.
* device.[ch]: Implementation of functions for the netdevice and for rtnl, responsible for maintaining the life of a given interface and wiring it up to the rest of WireGuard.
* peer.[ch]: Each interface has a list of peers, with helper functions available here for creation, destruction, and reference counting.
* socket.[ch]: Implementation of functions related to udp_socket and the general set of kernel socket APIs, for sending and receiving ciphertext UDP packets, and taking care of WireGuard-specific sticky socket routing semantics for the automatic roaming.
* netlink.[ch]: Userspace API entry point for configuring WireGuard peers and devices. The API has been implemented by several userspace tools and network management utility, and the WireGuard project distributes the basic wg(8) tool.
* queueing.[ch]: Shared function on the rx and tx path for handling the various queues used in the multicore algorithms.
* send.c: Handles encrypting outgoing packets in parallel on multiple cores, before sending them in order on a single core, via workqueues and ring buffers. Also handles sending handshake and cookie messages as part of the protocol, in parallel.
* receive.c: Handles decrypting incoming packets in parallel on multiple cores, before passing them off in order to be ingested via the rest of the networking subsystem with GRO via the typical NAPI poll function. Also handles receiving handshake and cookie messages as part of the protocol, in parallel.
* timers.[ch]: Uses the timer wheel to implement protocol particular event timeouts, and gives a set of very simple event-driven entry point functions for callers.
* main.c, version.h: Initialization and deinitialization of the module.
* selftest/*.h: Runtime unit tests for some of the most security sensitive functions.
* tools/testing/selftests/wireguard/netns.sh: Aforementioned testing script using network namespaces.
This commit aims to be as self-contained as possible, implementing WireGuard as a standalone module not needing much special handling or coordination from the network subsystem. I expect for future optimizations to the network stack to positively improve WireGuard, and vice-versa, but for the time being, this exists as intentionally standalone.
We introduce a menu option for CONFIG_WIREGUARD, as well as providing a verbose debug log and self-tests via CONFIG_WIREGUARD_DEBUG.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Cc: David Miller <davem@davemloft.net> Cc: Greg KH <gregkh@linuxfoundation.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: linux-crypto@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: netdev@vger.kernel.org Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
0fe9f173 |
| 13-May-2019 |
Florian Fainelli <f.fainelli@gmail.com> |
net: Always descend into dsa/
Jiri reported that with a kernel built with CONFIG_FIXED_PHY=y, CONFIG_NET_DSA=m and CONFIG_NET_DSA_LOOP=m, we would not get to a functional state where the mock-up dri
net: Always descend into dsa/
Jiri reported that with a kernel built with CONFIG_FIXED_PHY=y, CONFIG_NET_DSA=m and CONFIG_NET_DSA_LOOP=m, we would not get to a functional state where the mock-up driver is registered. Turns out that we are not descending into drivers/net/dsa/ unconditionally, and we won't be able to link-in dsa_loop_bdinfo.o which does the actual mock-up mdio device registration.
Reported-by: Jiri Pirko <jiri@resnulli.us> Fixes: 40013ff20b1b ("net: dsa: Fix functional dsa-loop dependency on FIXED_PHY") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com> Tested-by: Jiri Pirko <jiri@resnulli.us> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
cfc80d9a |
| 24-May-2018 |
Sridhar Samudrala <sridhar.samudrala@intel.com> |
net: Introduce net_failover driver
The net_failover driver provides an automated failover mechanism via APIs to create and destroy a failover master netdev and manages a primary and standby slave ne
net: Introduce net_failover driver
The net_failover driver provides an automated failover mechanism via APIs to create and destroy a failover master netdev and manages a primary and standby slave netdevs that get registered via the generic failover infrastructure.
The failover netdev acts a master device and controls 2 slave devices. The original paravirtual interface gets registered as 'standby' slave netdev and a passthru/vf device with the same MAC gets registered as 'primary' slave netdev. Both 'standby' and 'failover' netdevs are associated with the same 'pci' device. The user accesses the network interface via 'failover' netdev. The 'failover' netdev chooses 'primary' netdev as default for transmits when it is available with link up and running.
This can be used by paravirtual drivers to enable an alternate low latency datapath. It also enables hypervisor controlled live migration of a VM with direct attached VF by failing over to the paravirtual datapath when the VF is unplugged.
Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
3f2df32c |
| 09-Mar-2018 |
Arnd Bergmann <arnd@arndb.de> |
net: remove cris etrax ethernet driver
The cris architecture is getting removed, so we don't need the ethernet driver any more either.
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com> Signed-off-
net: remove cris etrax ethernet driver
The cris architecture is getting removed, so we don't need the ethernet driver any more either.
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
show more ...
|
#
83c9e13a |
| 01-Dec-2017 |
Jakub Kicinski <jakub.kicinski@netronome.com> |
netdevsim: add software driver for testing offloads
To be able to run selftests without any hardware required we need a software model. The model can also serve as an example implementation for tho
netdevsim: add software driver for testing offloads
To be able to run selftests without any hardware required we need a software model. The model can also serve as an example implementation for those implementing actual HW offloads. The dummy driver have previously been extended to test SR-IOV, but the general consensus seems to be against adding further features to it.
Add a new driver for purposes of software modelling only. eBPF and SR-IOV will be added here shortly, others are invited to further extend the driver with their offload models.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by: Simon Horman <simon.horman@netronome.com> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
show more ...
|