| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
| |
MFC after: 3 days
Sponsored by: Mellanox Technologies
Notes:
svn path=/head/; revision=347258
|
| |
|
|
|
|
|
|
| |
MFC after: 1 week
Sponsored by: Mellanox Technologies
Notes:
svn path=/head/; revision=345011
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Make sure the enter and leave polling routines can be called multiple times
with same setting. Ignore setting polling or event mode twice. This fixes a
deadlock during shutdown if polling mode was already selected.
MFC after: 1 week
Sponsored by: Mellanox Technologies
Notes:
svn path=/head/; revision=345010
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
mlx4_en_stop_port() calls mlx4_en_put_qp() which can refer the link level
address of the network interface, which in turn will be freed by the
network interface detach function. Make sure the port is stopped
before detaching the network interface.
MFC after: 1 week
Sponsored by: Mellanox Technologies
Notes:
svn path=/head/; revision=344920
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It can happen during shutdown that the lock will recurse when the mlx4en(4)
instance is part of a lagg interface. Call ether_ifdetach() unlocked.
Backtrace:
panic(): _sx_xlock_hard: recursed on non-recursive sx &mdev->state_lock
_sx_xlock_hard()
_sx_xlock()
mlx4_en_ioctl()
if_setlladdr()
lagg_port_destroy()
lagg_port_ifdetach()
if_detach()
mlx4_en_destroy_netdev()
mlx4_en_remove()
mlx4_remove_device()
mlx4_unregister_device()
mlx4_unload_one()
mlx4_shutdown()
linux_pci_shutdown()
bus_generic_shutdown()
MFC after: 1 week
Sponsored by: Mellanox Technologies
Notes:
svn path=/head/; revision=344919
|
| |
|
|
|
|
|
|
|
| |
Approved by: hselasky (mentor)
MFC after: 1 week
Sponsored by: Mellanox Technologies
Notes:
svn path=/head/; revision=341587
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Copy small packets like TCP ACKs into a new mbuf
reusing the existing mbuf to receive a new ethernet
frame. This avoids wasting buffer space for
small sized packets.
Submitted by: hselasky@
Approved by: hselasky (mentor)
MFC after: 1 week
Sponsored by: Mellanox Technologies
Notes:
svn path=/head/; revision=341552
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Adding an interface might be done outside the device_attach() routine
and will then cause a panic, due to the VNET not being defined.
Submitted by: hselasky@
Approved by: hselasky (mentor)
MFC after: 1 week
Sponsored by: Mellanox Technologies
Notes:
svn path=/head/; revision=341551
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The "priv->pkstats.rx_dropped" is written twice in a row.
Submitted by: hselasky@
Approved by: hselasky (mentor)
MFC after: 1 week
Sponsored by: Mellanox Technologies
Notes:
svn path=/head/; revision=341550
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
mbufs.
Also when the MTU is greater than MCLBYTES.
Submitted by: hselasky@
Approved by: hselasky (mentor)
MFC after: 1 week
Sponsored by: Mellanox Technologies
Notes:
svn path=/head/; revision=341549
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Implement the needed callback functions and support for polling the driver.
Differential Revision: https://reviews.freebsd.org/D15259
Approved by: hselasky (mentor)
MFC after: 1 week
Sponsored by: Mellanox Technologies
Notes:
svn path=/head/; revision=341548
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The hardware queues are deep enough currently and using the DRBR and associated
callbacks only leads to more task switching in the TX path. The is also a race
setting the queue_state which can lead to hung TX rings.
Submitted by: hselasky@
Approved by: hselasky (mentor)
MFC after: 1 week
Sponsored by: Mellanox Technologies
Notes:
svn path=/head/; revision=341547
|
| |
|
|
|
|
|
|
|
| |
Approved by: hselasky (mentor)
MFC after: 1 week
Sponsored by: Mellanox Technologies
Notes:
svn path=/head/; revision=341546
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
In last mlx4 update (r325841) we lost the sysctl to show the
firmware version for mlx4 devices.
Add both board identifier and firmware version under:
sys.device.mlx4_core0.hw sysctl node.
Approved by: hselasky (mentor)
MFC after: 1 week
Sponsored by: Mellanox Technologies
Notes:
svn path=/head/; revision=341545
|
| |
|
|
|
|
|
|
|
|
| |
Submitted by: hselasky@
Approved by: hselasky (mentor)
MFC after: 1 week
Sponsored by: Mellanox Technologies
Notes:
svn path=/head/; revision=341544
|
| |
|
|
|
|
|
|
|
|
| |
Submitted by: hselasky@
Approved by: hselasky (mentor)
MFC after: 1 week
Sponsored by: Mellanox Technologies
Notes:
svn path=/head/; revision=341543
|
| |
|
|
|
|
|
|
|
|
| |
Submitted by: hselasky@
Approved by: hselasky (mentor)
MFC after: 1 week
Sponsored by: Mellanox Technologies
Notes:
svn path=/head/; revision=341542
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When acting as a VF it is required to add steering rules for all unicast
addresses. Even if promiscious mode is selected. Else incoming data packets
will be dropped.
MFC after: 3 days
Approved by: re (gjb)
Sponsored by: Mellanox Technologies
Notes:
svn path=/head/; revision=339235
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When receiving a PCP change all GID entries are reloaded.
This ensures the relevant GID entries use prio tagging,
by setting VLAN present and VLAN ID to zero.
The priority for prio tagged traffic is set using the regular
rdma_set_service_type() function.
Fake the real network device to have a VLAN ID of zero
when prio tagging is enabled. This is logic is hidden inside
the rdma_vlan_dev_vlan_id() function which must always be used
to retrieve the VLAN ID throughout all of ibcore and the
infiniband network drivers.
The VLAN presence information then propagates through all
of ibcore and so incoming connections will have the VLAN
bit set. The incoming VLAN ID is then checked against the
return value of rdma_vlan_dev_vlan_id().
MFC after: 1 week
Sponsored by: Mellanox Technologies
Notes:
svn path=/head/; revision=336372
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Run on LLNW canaries and tested by pho@
gallatin:
Using a 14-core, 28-HTT single socket E5-2697 v3 with a 40GbE MLX5
based ConnectX 4-LX NIC, I see an almost 12% improvement in received
packet rate, and a larger improvement in bytes delivered all the way
to userspace.
When the host receiving 64 streams of netperf -H $DUT -t UDP_STREAM -- -m 1,
I see, using nstat -I mce0 1 before the patch:
InMpps OMpps InGbs OGbs err TCP Est %CPU syscalls csw irq GBfree
4.98 0.00 4.42 0.00 4235592 33 83.80 4720653 2149771 1235 247.32
4.73 0.00 4.20 0.00 4025260 33 82.99 4724900 2139833 1204 247.32
4.72 0.00 4.20 0.00 4035252 33 82.14 4719162 2132023 1264 247.32
4.71 0.00 4.21 0.00 4073206 33 83.68 4744973 2123317 1347 247.32
4.72 0.00 4.21 0.00 4061118 33 80.82 4713615 2188091 1490 247.32
4.72 0.00 4.21 0.00 4051675 33 85.29 4727399 2109011 1205 247.32
4.73 0.00 4.21 0.00 4039056 33 84.65 4724735 2102603 1053 247.32
After the patch
InMpps OMpps InGbs OGbs err TCP Est %CPU syscalls csw irq GBfree
5.43 0.00 4.20 0.00 3313143 33 84.96 5434214 1900162 2656 245.51
5.43 0.00 4.20 0.00 3308527 33 85.24 5439695 1809382 2521 245.51
5.42 0.00 4.19 0.00 3316778 33 87.54 5416028 1805835 2256 245.51
5.42 0.00 4.19 0.00 3317673 33 90.44 5426044 1763056 2332 245.51
5.42 0.00 4.19 0.00 3314839 33 88.11 5435732 1792218 2499 245.52
5.44 0.00 4.19 0.00 3293228 33 91.84 5426301 1668597 2121 245.52
Similarly, netperf reports 230Mb/s before the patch, and 270Mb/s after the patch
Reviewed by: gallatin
Sponsored by: Limelight Networks
Differential Revision: https://reviews.freebsd.org/D15366
Notes:
svn path=/head/; revision=333813
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes 32-bit compat (no ioctl command defintions are required
as struct ifreq is the same size). This is believed to be sufficent to
fully support ifconfig on 32-bit systems.
Reviewed by: kib
Obtained from: CheriBSD
MFC after: 1 week
Relnotes: yes
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D14900
Notes:
svn path=/head/; revision=331797
|
| |
|
|
|
|
|
|
| |
MFC after: 1 week
Sponsored by: Mellanox Technologies
Notes:
svn path=/head/; revision=330596
|
| |
|
|
|
|
|
|
| |
MFC after: 1 week
Sponsored by: Mellanox Technologies
Notes:
svn path=/head/; revision=330595
|
| |
|
|
|
|
|
|
| |
MFC after: 1 week
Sponsored by: Mellanox Technologies
Notes:
svn path=/head/; revision=330594
|
| |
|
|
|
|
|
|
|
|
|
| |
ethernet types.
Reviewed by: hselasky
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D14594
Notes:
svn path=/head/; revision=330537
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Creating a UD address handle from user-space or from the kernel-space,
when the link layer is ethernet, requires resolving the remote L3
address into a L2 address. Doing this from the kernel is easy because
the required ARP(IPv4) and ND6(IPv6) address resolving APIs are readily
available. In userspace such an interface does not exist and kernel
help is required.
It should be noted that in an IP-based GID environment, the GID itself
does not contain all the information needed to resolve the destination
IP address. For example information like VLAN ID and SCOPE ID, is not
part of the GID and must be fetched from the GID attributes. Therefore
a source GID should always be referred to as a GID index. Instead of
going through various racy steps to obtain information about the
GID attributes from user-space, this is now all done by the kernel.
This patch optimises the L3 to L2 address resolving using the existing
create address handle uverbs interface, retrieving back the L2 address
as an additional user-space information structure.
This commit combines the following Linux upstream commits:
IB/core: Let create_ah return extended response to user
IB/core: Change ib_resolve_eth_dmac to use it in create AH
IB/mlx5: Make create/destroy_ah available to userspace
IB/mlx5: Use kernel driver to help userspace create ah
IB/mlx5: Report that device has udata response in create_ah
MFC after: 1 week
Sponsored by: Mellanox Technologies
Notes:
svn path=/head/; revision=330508
|
| |
|
|
|
|
|
| |
Reviewed by: kib (D13858)
Notes:
svn path=/head/; revision=327864
|
| |
|
|
|
|
|
|
|
|
|
|
| |
These were made redundant in r325841.
Reviewed by: hselasky
MFC after: 1 week (hselasky will MFC)
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D13401
Notes:
svn path=/head/; revision=326666
|
| |\
| |
| |
| | |
Notes:
svn path=/projects/bsd_rdma_4_9/; revision=325842
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Background:
The coming ibcore update forces an update of mlx4ib(4) which in turn requires
an updated mlx4 core module. This also affects the mlx4en(4) module because
commonly used APIs are updated. This commit is a middle step updating the
mlx4 modules towards the new ibcore.
This change contains no major new features.
Changes in mlx4:
a) Improved error handling when mlx4 PCI devices are
detached inside VMs.
b) Major update of codebase towards Linux 4.9.
Changes in mlx4ib(4):
a) Minimal changes needed in order to compile using the
updated mlx4 core APIs.
Changes in mlx4en(4):
a) Update flow steering code in mlx4en to use new APIs for
registering MAC addresses and IP addresses.
b) Update all statistics counters to be 64-bit.
c) Minimal changes needed in order to compile using the
updated mlx4 core APIs.
Sponsored by: Mellanox Technologies
MFC after: 1 week
Notes:
svn path=/head/; revision=325841
|
| |/
|
|
|
|
|
| |
Sponsored by: Mellanox Technologies
Notes:
svn path=/projects/bsd_rdma_4_9/; revision=325760
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
iWarp and RoCE in ibcore. The selection of RDMA_PS_TCP can not be used
to indicate iWarp protocol use. Backport the proper IB device
capabilities from Linux upstream to distinguish between iWarp and
RoCE. Only allocate the additional socket required for iWarp for RDMA
IDs when at least one iWarp device present. This resolves
interopability issues between iWarp and RoCE in ibcore
Reviewed by: np @
Differential Revision: https://reviews.freebsd.org/D12563
Sponsored by: Mellanox Technologies
MFC after: 3 days
Notes:
svn path=/head/; revision=324792
|
| |
|
|
|
|
|
|
|
|
|
| |
Follow up from r324201 to fix compilation with gcc, which complains
about non-ICE case expressions.
Reviewed by: hselasky
Differential Revision: https://reviews.freebsd.org/D12675
Notes:
svn path=/head/; revision=324621
|
| |
|
|
|
|
|
|
|
|
| |
Submitted by: sephe@
Differential Revision: https://reviews.freebsd.org/D12229
MFC after: 1 week
Sponsored by: Mellanox Technologies
Notes:
svn path=/head/; revision=324201
|
| |
|
|
|
|
|
|
|
| |
Differential Revision: https://reviews.freebsd.org/D12176
MFC after: 1 week
Sponsored by: Mellanox Technologies
Notes:
svn path=/head/; revision=324200
|
| |
|
|
|
|
|
|
|
|
|
| |
Useful for debugging.
Submitted by: Sepherosa Ziehau <sephe@dragonflybsd.org>
MFC after: 3 days
Sponsored by: Mellanox Technologies
Notes:
svn path=/head/; revision=322306
|
| |
|
|
|
|
|
|
|
|
|
| |
are dropped by the mlx4en(4) driver.
Submitted by: Sepherosa Ziehau <sephe@dragonflybsd.org>
MFC after: 3 days
Sponsored by: Mellanox Technologies
Notes:
svn path=/head/; revision=322305
|
| |
|
|
|
|
|
|
|
|
|
| |
is in VF or SRIOV mode typically in a virtual machine environment.
Submitted by: Sepherosa Ziehau <sephe@dragonflybsd.org>
MFC after: 3 days
Sponsored by: Mellanox Technologies
Notes:
svn path=/head/; revision=322304
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The m_defrag() function can only defrag mbuf chains which have a valid
mbuf packet header. In r291699 when the mlx4en(4) driver was converted
into using BUSDMA(9), the call to m_defrag() was moved after the part
of the transmit routine which strips the header from the mbuf chain.
This effectivly disabled the mbuf defrag mechanism and such packets
simply got dropped.
This patch removes the stripping of mbufs from a chain and loads all
mbufs using busdma. If busdma finds there are no segments, unload
the DMA map and free the mbuf right away, because that means all
data in the mbuf has been inlined in the TX ring. Else proceed
as usual.
Add a per-ring rounter for the number of defrag attempts and
make sure the oversized_packets counter gets zeroed while at it.
The counters are per-ring to avoid excessive cache misses in the
TX path.
Submitted by: mjoras@
Differential Revision: https://reviews.freebsd.org/D11683
MFC after: 1 week
Sponsored by: Mellanox Technologies
Notes:
svn path=/head/; revision=322248
|
| |
|
|
|
|
|
|
|
|
|
| |
mlx4en driver which is used by its Linux counterpart, but not under
FreeBSD.
Sponsored by: Mellanox Technologies
MFC after: 1 week
Notes:
svn path=/head/; revision=321782
|
| |
|
|
|
|
|
|
| |
Sponsored by: Mellanox Technologies
MFC after: 1 week
Notes:
svn path=/head/; revision=321780
|
| |
|
|
|
|
|
|
|
|
|
| |
- return value has too small width
- cycle_t is unsigned and cannot be less than zero
Sponsored by: Mellanox Technologies
MFC after: 1 week
Notes:
svn path=/head/; revision=321772
|
| |
|
|
|
|
|
|
|
|
|
| |
in order to prevent the flow of QP to error in the firmware once
UPDATE_QP is called.
MFC after: 3 days
Sponsored by: Mellanox Technologies
Notes:
svn path=/head/; revision=320876
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Add io_mapping_init_wc() and add a third (unused) parameter to
io_mapping_map_wc().
Reviewed by: hselasky
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D11286
Notes:
svn path=/head/; revision=320196
|
| |
|
|
|
|
|
|
|
|
|
|
| |
mlx4en network interfaces. This prevents infinite unit number growth
typically when the mlx4en driver is used inside virtual machines which
support runtime PCI attach and detach.
MFC after: 3 days
Sponsored by: Mellanox Technologies
Notes:
svn path=/head/; revision=319972
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mlx4en(4) driver in SRIOV mode.
Place a copy of the destination MAC address in the send WQE only under
SRIOV/eSwitch configuration or when the device is in selftest. This
allows communication between functions on the same host.
PR: 216493
MFC after: 3 days
Sponsored by: Mellanox Technologies
Notes:
svn path=/head/; revision=319414
|
| |
|
|
|
|
|
|
|
|
|
|
| |
driver. Else if the port is up the resource might still be busy and
the MTT free will fail.
PR: 216493
MFC after: 3 days
Sponsored by: Mellanox Technologies
Notes:
svn path=/head/; revision=319413
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When creating EQs to handle CQ completion events for the PF or for
VFs, we create enough EQE entries to handle completions for the max
number of CQs that can use that EQ.
When SRIOV is activated, the max number of CQs a VF (or the PF) can
obtain is its CQ quota (determined by the Hypervisor resource
tracker). Therefore, when creating an EQ, the number of EQE entries
that the VF should request for that EQ is the CQ quota value (and not
the total number of CQs available in the firmware).
Under SRIOV, the PF, also must use its CQ quota, because the resource
tracker also controls how many CQs the PF can obtain.
Using the firmware total CQs instead of the CQ quota when creating EQs
resulted wasting MTT entries, due to allocating more EQEs than were
needed.
MFC after: 3 days
Sponsored by: Mellanox Technologies
Notes:
svn path=/head/; revision=318531
|
| |
|
|
|
|
|
|
|
|
|
| |
can cause NULL pointer panics during failed device attach.
Differential Revision: https://reviews.freebsd.org/D8876
MFC after: 1 week
Sponsored by: Mellanox Technologies
Notes:
svn path=/head/; revision=317505
|
| |
|
|
|
|
|
|
|
| |
Found by: emaste @
MFC after: 1 week
Sponsored by: Mellanox Technologies
Notes:
svn path=/head/; revision=313778
|