#
60c317af |
| 01-Dec-2014 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r275262 through r275363.
|
#
c2529042 |
| 01-Dec-2014 |
Hans Petter Selasky <hselasky@FreeBSD.org> |
Start process of removing the use of the deprecated "M_FLOWID" flag 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. In
Start process of removing the use of the deprecated "M_FLOWID" flag 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
show more ...
|
#
9268022b |
| 19-Nov-2014 |
Simon J. Gerraty <sjg@FreeBSD.org> |
Merge from head@274682
|
Revision tags: release/10.1.0 |
|
#
5c9ef378 |
| 04-Nov-2014 |
Alexander V. Chernikov <melifaro@FreeBSD.org> |
Sync to HEAD@r274095.
|
#
854f7e89 |
| 21-Oct-2014 |
Bryan Venteicher <bryanv@FreeBSD.org> |
Use the size of the Ethernet address, not the entire header, when copying into forwarding entry.
Reported by: Coverity CID: 1248849
|
#
408ea865 |
| 21-Oct-2014 |
Neel Natu <neel@FreeBSD.org> |
IFC @r273338
|
#
007054f0 |
| 20-Oct-2014 |
Bryan Venteicher <bryanv@FreeBSD.org> |
Add vxlan interface
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 complian
Add vxlan interface
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
show more ...
|