aboutsummaryrefslogtreecommitdiff
path: root/sys/net/if_vxlan.c
Commit message (Collapse)AuthorAgeFilesLines
* vxlan: stop checking CSUM_ENCAP_VXLAN when converting inner CSUM flags into ↵Konstantin Belousov2020-12-231-2/+1
| | | | | | | | | | | | | | | | normal, for decapsulation. The packet, if processed at this point, was already parsed to be UDP directed to a vxlan port. Connect-X 4+ does not provide easy method to infer which parser processed the packet, so driver cannot set the flag without a lot of efforts which are only to satisfy the formal requirements. Reviewed by: bryanv, np Sponsored by: Mellanox Technologies/NVidia Networking Differential revision: https://reviews.freebsd.org/D27449 MFC after: 1 week
* if_vxlan(4): csum_flags_to_inner_flags takes the tunnel protocol as a parameter.Navdeep Parhar2020-10-221-2/+2
| | | | | | | No functional change. Notes: svn path=/head/; revision=366941
* if_vxlan(4): add support for hardware assisted checksumming, TSO, and RSS.Navdeep Parhar2020-09-181-21/+469
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This lets a VXLAN pseudo-interface take advantage of hardware checksumming (tx and rx), TSO, and RSS if the NIC is capable of performing these operations on inner VXLAN traffic. A VXLAN interface inherits the capabilities of its vxlandev interface if one is specified or of the interface that hosts the vxlanlocal address. If other interfaces will carry traffic for that VXLAN then they must have the same hardware capabilities. On transmit, if_vxlan verifies that the outbound interface has the required capabilities and then translates the CSUM_ flags to their inner equivalents. This tells the hardware ifnet that it needs to operate on the inner frame and not the outer VXLAN headers. An event is generated when a VXLAN ifnet starts. This allows hardware drivers to configure their devices to expect VXLAN traffic on the specified incoming port. On receive, the hardware does RSS and checksum verification on the inner frame. if_vxlan now does a direct netisr dispatch to take full advantage of RSS. It is not very clear why it didn't do this already. Future work: Rx: it should be possible to avoid the first trip up the protocol stack to get the frame to if_vxlan just so it can decapsulate and requeue for a second trip up the stack. The hardware NIC driver could directly call an if_vxlan receive routine for VXLAN traffic instead. Rx: LRO. depends on what happens with the previous item. There will have to to be a mechanism to indicate that it's time for if_vxlan to flush its LRO state. Reviewed by: kib@ Relnotes: Yes Sponsored by: Chelsio Communications Differential Revision: https://reviews.freebsd.org/D25873 Notes: svn path=/head/; revision=365870
* Correct the mask byte order when checking for reserved bits.Qing Li2020-08-151-1/+1
| | | | | | | | | | Reviewed by: gnn Approved by: gnn MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D26071 Notes: svn path=/head/; revision=364257
* Mark more nodes as CTLFLAG_MPSAFE or CTLFLAG_NEEDGIANT (17 of many)Pawel Biernacki2020-02-261-4/+4
| | | | | | | | | | | | | | | | | | | r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are still not MPSAFE (or already are but aren’t properly marked). Use it in preparation for a general review of all nodes. This is non-functional change that adds annotations to SYSCTL_NODE and SYSCTL_PROC nodes using one of the soon-to-be-required flags. Mark all obvious cases as MPSAFE. All entries that haven't been marked as MPSAFE before are by default marked as NEEDGIANT Approved by: kib (mentor, blanket) Commented by: kib, gallatin, melifaro Differential Revision: https://reviews.freebsd.org/D23718 Notes: svn path=/head/; revision=358333
* Allow set MTU more than 1500 bytes.Kirill Ponomarev2019-07-241-3/+20
| | | | | | | | | | Submitted by: Alexandr Fedorov <aleksandr.fedorov_itglobal_dot_com> Approved by: jhb, rgrimes Sponsored by: ITGlobal.com Differential Revision: https://reviews.freebsd.org/D19422 Notes: svn path=/head/; revision=350293
* Convert all IPv4 and IPv6 multicast memberships into using a STAILQHans Petter Selasky2019-06-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | instead of a linear array. The multicast memberships for the inpcb structure are protected by a non-sleepable lock, INP_WLOCK(), which needs to be dropped when calling the underlying possibly sleeping if_ioctl() method. When using a linear array to keep track of multicast memberships, the computed memory location of the multicast filter may suddenly change, due to concurrent insertion or removal of elements in the linear array. This in turn leads to various invalid memory access issues and kernel panics. To avoid this problem, put all multicast memberships on a STAILQ based list. Then the memory location of the IPv4 and IPv6 multicast filters become fixed during their lifetime and use after free and memory leak issues are easier to track, for example by: vmstat -m | grep multi All list manipulation has been factored into inline functions including some macros, to easily allow for a future hash-list implementation, if needed. This patch has been tested by pho@ . Differential Revision: https://reviews.freebsd.org/D20080 Reviewed by: markj @ MFC after: 1 week Sponsored by: Mellanox Technologies Notes: svn path=/head/; revision=349369
* net: adjust randomized address bitsKyle Evans2019-04-171-1/+1
| | | | | | | | | | | | | Give devices that need a MAC a 16-bit allocation out of the FreeBSD Foundation OUI range. Change the name ether_fakeaddr to ether_gen_addr now that we're dealing real MAC addresses with a real OUI rather than random locally-administered addresses. Reviewed by: bz, rgrimes Differential Revision: https://reviews.freebsd.org/D19587 Notes: svn path=/head/; revision=346324
* ether: centralize fake hwaddr generationKyle Evans2019-03-141-18/+3
| | | | | | | | | | | | We currently have two places with identical fake hwaddr generation -- if_vxlan and if_bridge. Lift it into if_ethersubr for reuse in other interfaces that may also need a fake addr. Reviewed by: bryanv, kp, philip Differential Revision: https://reviews.freebsd.org/D19573 Notes: svn path=/head/; revision=345139
* net: fix set but not usedMatt Macy2018-05-191-4/+5
| | | | Notes: svn path=/head/; revision=333864
* Add macro for vxlan list mutex lock and unlockBryan Venteicher2017-12-301-8/+12
| | | | | | | | | | This will simplify some later VNET support. Submitted by: hrs MFC after: 2 weeks Notes: svn path=/head/; revision=327386
* Advertise IFCAP_LINKSTAT after r326480 added link status supportBryan Venteicher2017-12-301-0/+2
| | | | | | | MFC after: 2 weeks Notes: svn path=/head/; revision=327385
* Add support for IPv6 scoped addresses to vxlanBryan Venteicher2017-12-301-27/+89
| | | | | | | MFC after: 2 weeks Notes: svn path=/head/; revision=327375
* Fix possible memory leak.Andrey V. Elsukov2017-12-161-1/+1
| | | | | | | | | | | | | | vxlan_ftable entries are sorted in ascending order, due to wrong arguments order it is possible to stop search before existing element will be found. Then new element will be allocated in vxlan_ftable_update_locked() and can be inserted in the list second time or trigger MPASS() assertion with enabled INVARIANTS. PR: 224371 MFC after: 1 week Notes: svn path=/head/; revision=326898
* Add if media and link status events to vxlanBryan Venteicher2017-12-021-0/+33
| | | | | | | | PR: 214359 MFC after: 2 weeks Notes: svn path=/head/; revision=326480
* net: Use M_HASHTYPE_OPAQUE_HASH if the mbuf flowid has hash propertiesSepherosa Ziehau2016-06-071-2/+1
| | | | | | | | | Reviewed by: hps, erj, tuexen Sponsored by: Microsoft OSTC Differential Revision: https://reviews.freebsd.org/D6688 Notes: svn path=/head/; revision=301538
* Complete the UDP tunneling of ICMP msgs to those protocolsRandall Stewart2016-04-281-1/+1
| | | | | | | | | | | interested in having tunneled UDP and finding out about the ICMP (tested by Michael Tuexen with SCTP.. soon to be using this feature). Differential Revision: http://reviews.freebsd.org/D5875 Notes: svn path=/head/; revision=298747
* Start process of removing the use of the deprecated "M_FLOWID" flagHans Petter Selasky2014-12-011-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | from the FreeBSD network code. The flag is still kept around in the "sys/mbuf.h" header file, but does no longer have any users. Instead the "m_pkthdr.rsstype" field in the mbuf structure is now used to decide the meaning of the "m_pkthdr.flowid" field. To modify the "m_pkthdr.rsstype" field please use the existing "M_HASHTYPE_XXX" macros as defined in the "sys/mbuf.h" header file. This patch introduces new behaviour in the transmit direction. Previously network drivers checked if "M_FLOWID" was set in "m_flags" before using the "m_pkthdr.flowid" field. This check has now now been replaced by checking if "M_HASHTYPE_GET(m)" is different from "M_HASHTYPE_NONE". In the future more hashtypes will be added, for example hashtypes for hardware dedicated flows. "M_HASHTYPE_OPAQUE" indicates that the "m_pkthdr.flowid" value is valid and has no particular type. This change removes the need for an "if" statement in TCP transmit code checking for the presence of a valid flowid value. The "if" statement mentioned above is now a direct variable assignment which is then later checked by the respective network drivers like before. Additional notes: - The SCTP code changes will be committed as a separate patch. - Removal of the "M_FLOWID" flag will also be done separately. - The FreeBSD version has been bumped. MFC after: 1 month Sponsored by: Mellanox Technologies Notes: svn path=/head/; revision=275358
* Use the size of the Ethernet address, not the entire header, whenBryan Venteicher2014-10-211-1/+1
| | | | | | | | | | copying into forwarding entry. Reported by: Coverity CID: 1248849 Notes: svn path=/head/; revision=273371
* Add vxlan interfaceBryan Venteicher2014-10-201-0/+3089
vxlan creates a virtual LAN by encapsulating the inner Ethernet frame in a UDP packet. This implementation is based on RFC7348. Currently, the IPv6 support is not fully compliant with the specification: we should be able to receive UPDv6 packets with a zero checksum, but we need to support RFC6935 first. Patches for this should come soon. Encapsulation protocols such as vxlan emphasize the need for the FreeBSD network stack to support batching, GRO, and GSO. Each frame has to make two trips through the network stack, and each frame will be at most MTU sized. Performance suffers accordingly. Some latest generation NICs have begun to support vxlan HW offloads that we should also take advantage of. VIMAGE support should also be added soon. Differential Revision: https://reviews.freebsd.org/D384 Reviewed by: gnn Relnotes: yes Notes: svn path=/head/; revision=273331
generated by cgit v1.3 (git 2.53.0) at 2026-04-09 18:21:51 +0000