History log of /freebsd/sys/ofed/drivers/infiniband/core/ib_addr.c (Results 1 – 25 of 30)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: release/14.0.0
# 685dc743 16-Aug-2023 Warner Losh <imp@FreeBSD.org>

sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/


Revision tags: release/13.2.0
# 3e142e07 09-Feb-2023 Justin Hibbits <jhibbits@FreeBSD.org>

ofed: Mechanically convert to IfAPI

Summary:
Because of the intricacies of this code it wasn't purely scripted, but
instead hand-mechanical.

Reviewed by: hselasky
Sponsored by: Juniper Networks, In

ofed: Mechanically convert to IfAPI

Summary:
Because of the intricacies of this code it wasn't purely scripted, but
instead hand-mechanical.

Reviewed by: hselasky
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D38560

show more ...


Revision tags: release/12.4.0
# 57af517a 22-Aug-2022 Hans Petter Selasky <hselasky@FreeBSD.org>

ibcore: Add support for RDMA/RoCE using VLAN(4) devices.

Classify VLAN devices as ethernet in rdma_copy_addr().
This fixes the following error message:

rdma_bind_addr: No such file or directory

Su

ibcore: Add support for RDMA/RoCE using VLAN(4) devices.

Classify VLAN devices as ethernet in rdma_copy_addr().
This fixes the following error message:

rdma_bind_addr: No such file or directory

Submitted by: bartosz.sobczak@intel.com (Bartosz Sobczak)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D36120
Sponsored by: NVIDIA Networking

show more ...


Revision tags: release/13.1.0
# fc99316e 03-Mar-2022 Hans Petter Selasky <hselasky@FreeBSD.org>

ibcore: Fix multiple includes of same header file.

MFC after: 1 week
Sponsored by: NVIDIA Networking


Revision tags: release/12.3.0
# 62e1a437 23-Aug-2021 Zhenlei Huang <zlei.huang@gmail.com>

routing: Allow using IPv6 next-hops for IPv4 routes (RFC 5549).

Implement kernel support for RFC 5549/8950.

* Relax control plane restrictions and allow specifying IPv6 gateways
for IPv4 routes. T

routing: Allow using IPv6 next-hops for IPv4 routes (RFC 5549).

Implement kernel support for RFC 5549/8950.

* Relax control plane restrictions and allow specifying IPv6 gateways
for IPv4 routes. This behavior is controlled by the
net.route.rib_route_ipv6_nexthop sysctl (on by default).

* Always pass final destination in ro->ro_dst in ip_forward().

* Use ro->ro_dst to exract packet family inside if_output() routines.
Consistently use RO_GET_FAMILY() macro to handle ro=NULL case.

* Pass extracted family to nd6_resolve() to get the LLE with proper encap.
It leverages recent lltable changes committed in c541bd368f86.

Presence of the functionality can be checked using ipv4_rfc5549_support feature(3).
Example usage:
route add -net 192.0.0.0/24 -inet6 fe80::5054:ff:fe14:e319%vtnet0

Differential Revision: https://reviews.freebsd.org/D30398
MFC after: 2 weeks

show more ...


# c541bd36 21-Aug-2021 Alexander V. Chernikov <melifaro@FreeBSD.org>

lltable: Add support for "child" LLEs holding encap for IPv4oIPv6 entries.

Currently we use pre-calculated headers inside LLE entries as prepend data
for `if_output` functions. Using these headers

lltable: Add support for "child" LLEs holding encap for IPv4oIPv6 entries.

Currently we use pre-calculated headers inside LLE entries as prepend data
for `if_output` functions. Using these headers allows saving some
CPU cycles/memory accesses on the fast path.

However, this approach makes adding L2 header for IPv4 traffic with IPv6
nexthops more complex, as it is not possible to store multiple
pre-calculated headers inside lle. Additionally, the solution space is
limited by the fact that PCB caching saves LLEs in addition to the nexthop.

Thus, add support for creating special "child" LLEs for the purpose of holding
custom family encaps and store mbufs pending resolution. To simplify handling
of those LLEs, store them in a linked-list inside a "parent" (e.g. normal) LLE.
Such LLEs are not visible when iterating LLE table. Their lifecycle is bound
to the "parent" LLE - it is not possible to delete "child" when parent is alive.
Furthermore, "child" LLEs are static (RTF_STATIC), avoding complex state
machine used by the standard LLEs.

nd6_lookup() and nd6_resolve() now accepts an additional argument, family,
allowing to return such child LLEs. This change uses `LLE_SF()` macro which
packs family and flags in a single int field. This is done to simplify merging
back to stable/. Once this code lands, most of the cases will be converted to
use a dedicated `family` parameter.

Differential Revision: https://reviews.freebsd.org/D31379
MFC after: 2 weeks

show more ...


# 1411f52f 04-Jun-2021 Bjoern A. Zeeb <bz@FreeBSD.org>

mlx4/OFED: replace the struct net_device with struct ifnet

Given all the code does operate on struct ifnet, the last step in this
longer series of changes now is to rename struct net_device to
struc

mlx4/OFED: replace the struct net_device with struct ifnet

Given all the code does operate on struct ifnet, the last step in this
longer series of changes now is to rename struct net_device to
struct ifnet (that is what it was defined to in the LinuxKPi code).
While mlx4 and OFED are "shared" code the decision was made years ago
to not write it based on the netdevice KPI but the native ifnet KPI
for most of it. This commit simply spells this out and with that
frees "struct netdevice" to be re-done on LinuxKPI to become a more
native/mixed implementation over time as needed by, e.g., wireless
drivers.

Sponsored by: The FreeBSD Foundation
MFC after: 10 days
Reviewed by: hselasky
Differential Revision: https://reviews.freebsd.org/D30515

show more ...


# c35034b3 26-May-2021 Bjoern A. Zeeb <bz@FreeBSD.org>

LinuxKPI/OFED/mlx4: cleanup netdevice.h some more

This removes all unused bits from linux/netdevice.h and migrates two
inline functions into the mlx4 and ofed code respectively.

This gets the mlx4/

LinuxKPI/OFED/mlx4: cleanup netdevice.h some more

This removes all unused bits from linux/netdevice.h and migrates two
inline functions into the mlx4 and ofed code respectively.

This gets the mlx4/ofed (struct ifnet) specific bits down to 7 lines
in netdevice.h.

Sponsored by: The FreeBSD Foundation
MFC after: 13 days
Reviewed by: hselasky, kib
Differential Revision: https://reviews.freebsd.org/D30461

show more ...


Revision tags: release/13.0.0
# 7069b4c6 26-Mar-2021 Bjoern A. Zeeb <bz@FreeBSD.org>

LinuxKPI/OFED: (re)move inetdevice.h implementation

The two functions in linux/inetdevice.h are highly FreeBSD/ifnet
specific. This is a result of struct net_device being mapped to
struct ifnet.

T

LinuxKPI/OFED: (re)move inetdevice.h implementation

The two functions in linux/inetdevice.h are highly FreeBSD/ifnet
specific. This is a result of struct net_device being mapped to
struct ifnet.

The only known consumer of these functions are two files in the
ofed/infiniband code.

As a first step of cleaning up copy linux/inetdevice.h to
rdma/ib_addr_freebsd.h. (It stayed a separate file to preserve
copyright and license of the original file; otherwise it could be
merged into ib_addr.h where more EPOCH/vnet/.. are already used).

Slightly rename the function to not conflict with LinuxKPI
in the future.

Remove the three last, now unneeded includes of inetdevice.h and
zap linux/inetdevice.h to an empty header file with only the forward
include to netdevice.h remaining.

Sponsored-by: The FreeBSD Foundation
MFC-after: 2 weeks
Reviewed-by: hselasky, kib
X-D-R: D29366 (extracted as further cleanup)
Differential Revision: https://reviews.freebsd.org/D29434

show more ...


Revision tags: release/12.2.0
# 536457e1 31-Aug-2020 Eric van Gyzen <vangyzen@FreeBSD.org>

infiniband: Appease Coverty

Coverity claims the call to rdma_gid2ip in cma_igmp_send overwrites addr.
Use a consistent definition of sockaddr to prevent detections and code
changes in the future.

S

infiniband: Appease Coverty

Coverity claims the call to rdma_gid2ip in cma_igmp_send overwrites addr.
Use a consistent definition of sockaddr to prevent detections and code
changes in the future.

Submitted by: bret_ketchum@dell.com
Reported by: Coverity
Reviewed by: hselasky, kib
MFC after: 2 weeks
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D26229

show more ...


Revision tags: release/11.4.0
# 0f3bf682 15-Apr-2020 Alexander V. Chernikov <melifaro@FreeBSD.org>

Convert OFED rtable interactions to the new routing KPI.

Reviewed by: hselasky
Differential Revision: https://reviews.freebsd.org/D24387


Revision tags: release/12.1.0
# 06656d75 15-Oct-2019 Hans Petter Selasky <hselasky@FreeBSD.org>

Fix missing epochification of the ibcore code after r353292.

Sponsored by: Mellanox Technologies


Revision tags: release/11.3.0
# 67350cb5 09-Dec-2018 Dimitry Andric <dim@FreeBSD.org>

Merge ^/head r340918 through r341763.


Revision tags: release/12.0.0
# e13619b6 05-Dec-2018 Slava Shwartsman <slavash@FreeBSD.org>

ibcore: Fix clearing of bound device interface.

Binding to a loopback device is not allowed. Make sure the destination
device address is global by clearing the bound device interface.
Only do this c

ibcore: Fix clearing of bound device interface.

Binding to a loopback device is not allowed. Make sure the destination
device address is global by clearing the bound device interface.
Only do this conditionally, else link local addresses won't work.

Submitted by: hselasky@
Approved by: hselasky (mentor)
MFC after: 1 week
Sponsored by: Mellanox Technologies

show more ...


# a9c20af2 05-Dec-2018 Slava Shwartsman <slavash@FreeBSD.org>

ibcore: ip6_dev_find() needs to know the scope ID.

Else the wrong network device can be returned for link-local addresses.

Submitted by: hselasky@
Approved by: hselasky (mentor)
MFC after:

ibcore: ip6_dev_find() needs to know the scope ID.

Else the wrong network device can be returned for link-local addresses.

Submitted by: hselasky@
Approved by: hselasky (mentor)
MFC after: 1 week
Sponsored by: Mellanox Technologies

show more ...


# cda1e10c 17-Jul-2018 Hans Petter Selasky <hselasky@FreeBSD.org>

Use __FBSDID() for RCS tags in ibcore.

MFC after: 1 week
Sponsored by: Mellanox Technologies


# 02825401 17-Jul-2018 Hans Petter Selasky <hselasky@FreeBSD.org>

Fix for loopback detection in address resolve logic in ibcore.

When a loopback address is detected use the network interface which
has the loopback flag set to trigger loopback logic in address reso

Fix for loopback detection in address resolve logic in ibcore.

When a loopback address is detected use the network interface which
has the loopback flag set to trigger loopback logic in address resolve.

MFC after: 1 week
Sponsored by: Mellanox Technologies

show more ...


# 855ad7cf 17-Jul-2018 Hans Petter Selasky <hselasky@FreeBSD.org>

Check AF family prior resolving address and introduce safer rdma_addr_size() variants in ibcore.

Garbage supplied by user will cause to UCMA module provide zero
memory size for memcpy(), because it

Check AF family prior resolving address and introduce safer rdma_addr_size() variants in ibcore.

Garbage supplied by user will cause to UCMA module provide zero
memory size for memcpy(), because it wasn't checked, it will
produce unpredictable results in rdma_resolve_addr().

There are several places in the ucma ABI where userspace can pass in a
sockaddr but set the address family to AF_IB. When that happens,
rdma_addr_size() will return a size bigger than sizeof struct sockaddr_in6,
and the ucma kernel code might end up copying past the end of a buffer
not sized for a struct sockaddr_ib.

Fix this by introducing new variants
int rdma_addr_size_in6(struct sockaddr_in6 *addr);
int rdma_addr_size_kss(struct __kernel_sockaddr_storage *addr);

that are type-safe for the types used in the ucma ABI and return 0 if the
size computed is bigger than the size of the type passed in. We can use
these new variants to check what size userspace has passed in before
copying any addresses.

Linux commit:
2975d5de6428ff6d9317e9948f0968f7d42e5d74
09abfe7b5b2f442a85f4c4d59ecf582ad76088d7
84652aefb347297aa08e91e283adf7b18f77c2d5

MFC after: 1 week
Sponsored by: Mellanox Technologies

show more ...


# fed17c58 17-Jul-2018 Hans Petter Selasky <hselasky@FreeBSD.org>

Fix for RDMA loopback over VLAN in ibcore.

Implement a more generic solution for detecting loopback.
The problem was that the default netdevice was resolved
for loopback also when VLAN was used. Use

Fix for RDMA loopback over VLAN in ibcore.

Implement a more generic solution for detecting loopback.
The problem was that the default netdevice was resolved
for loopback also when VLAN was used. Use real network
device instead of loopback device for bound device
interface.

How to test:
ucmatose -b 127.0.0.1 -p 20090
ucmatose -s 5.6.5.1 -p 20090

Note that RDMA treats the IPv4 and IPv6 loopback
addresses like any address.

MFC after: 1 week
Sponsored by: Mellanox Technologies

show more ...


# f9899e45 17-Jul-2018 Hans Petter Selasky <hselasky@FreeBSD.org>

Add native FreeBSD support for multicast in ibcore.

This change adds support for registering multicast addresses,
both IPv4 and IPv6.

MFC after: 1 week
Sponsored by: Mellanox Technologies


# 8b767bd7 17-Jul-2018 Hans Petter Selasky <hselasky@FreeBSD.org>

Only update source address when resolving is successful in ibcore.

When resolving an IP address in ibcore, only update the source address
upon normal completion. The ibcore address resolve function

Only update source address when resolving is successful in ibcore.

When resolving an IP address in ibcore, only update the source address
upon normal completion. The ibcore address resolve function does not
care about the scope ID value of the IPv6 link-local addresses and expects
this information has already been extracted into the bound_dev_if field.
Because the same IPv6 link-local address can exist on multiple interfaces
the ibcore address resolver gets confused and returns ENETUNREACH.

Instead of updating both source address and bound_dev_if just keep the
address set to any address until resolving completes. For the sake of code
symmetry a similar change has been applied to the IPv4 address resolve path.

MFC after: 1 week
Sponsored by: Mellanox Technologies

show more ...


# e0cba2d2 17-Jul-2018 Hans Petter Selasky <hselasky@FreeBSD.org>

Process address resolve requests at least one time per second in ibcore.

When setting a large address resolve timeout it was observed that the
address resolving would succeed at the timeout and not

Process address resolve requests at least one time per second in ibcore.

When setting a large address resolve timeout it was observed that the
address resolving would succeed at the timeout and not when the address
was available. Make sure the address resolving requests are processed no
slower than one time every second.

While at it use "int" for jiffies instead of "unsigned long" to match
FreeBSD ticks.

MFC after: 1 week
Sponsored by: Mellanox Technologies

show more ...


Revision tags: release/11.2.0
# aa5962f9 07-Mar-2018 Hans Petter Selasky <hselasky@FreeBSD.org>

Define values instead of using hardcoding.

MFC after: 1 week
Sponsored by: Mellanox Technologies


# cc79d31d 07-Mar-2018 Hans Petter Selasky <hselasky@FreeBSD.org>

Embed the IPv6 scope ID before calling rtalloc1() in ibcore.
Else rtalloc1() will resolve to the loopback interface.

MFC after: 1 week
Sponsored by: Mellanox Technologies


# bf8641fe 05-Mar-2018 Hans Petter Selasky <hselasky@FreeBSD.org>

Get correct network device when accepting incoming RDMA connections in ibcore.

This patch ensures the GID index is always used as a basis of resolving
incoming RDMA connections, as compared to the G

Get correct network device when accepting incoming RDMA connections in ibcore.

This patch ensures the GID index is always used as a basis of resolving
incoming RDMA connections, as compared to the GID value itself.

Background:
On a per infiniband port basis, the GID identifier is not a unique identifier!
This assumption falls apart when VLAN ID, IPv6 scope ID and RoCE type,
as supported by RoCE v2, is taken into account. This additional
information is stored in the so-called GID attributes and is needed to
correctly identify the destination network interface for an incoming
connection.

Different VLANs are allowed to define the same IPv4 addresses and especially
for the default IPv6 link-local addresses or when using so-called containers
or jails, this is true.

The VNET information for the destination network interface is needed in
order to perform the L2 address lookup in the right Virtual Network Stack
context.

Consequently old functions previously used by RoCE v1, like
rdma_addr_find_smac_by_sgid() are impossible to support, because
there can be multiple identical GIDs associated with the same
infiniband port, and the answer to such a request becomes undefined.
This function has been removed.

MFC after: 1 week
Sponsored by: Mellanox Technologies

show more ...


12