roundup_pow_of_two: don't take the log of it

Based on the definitions, ilog2(roundup_pow_of_two(x)) ==
order_base_2(x). Replace the former with the latter in a few places to
save a few calculations.

roundup_pow_of_two: don't take the log of it

Based on the definitions, ilog2(roundup_pow_of_two(x)) ==
order_base_2(x). Replace the former with the latter in a few places to
save a few calculations.

Reviewed by: bz, kib
Differential Revision: https://reviews.freebsd.org/D46827

show more ...

Mechanically convert mlx4(4) to IfAPI

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

mlx4: rename conflicting netdev_priv() to mlx4_netdev_priv()

netdev_priv() is a LinuxKPI function which was used with the old ifnet
linux/netdevice.h implementation which was not adaptable to modern

mlx4: rename conflicting netdev_priv() to mlx4_netdev_priv()

netdev_priv() is a LinuxKPI function which was used with the old ifnet
linux/netdevice.h implementation which was not adaptable to modern
Linux drviers unless rewriting them for ifnet in first place which
defeats the purpose.
Rename the netdev_priv() calls in mlx4 to mlx4_netdev_priv()
returning the ifnet softc to avoid conflicting symbol names
with different implementations in the future.

MFC after: 3 days
Reviewed by: hselasky, kib
Differential Revision: https://reviews.freebsd.org/D32640

show more ...

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 ...

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 ...

Split out a more generic debugnet(4) from netdump(4)

Debugnet is a simplistic and specialized panic- or debug-time reliable
datagram transport. It can drive a single connection at a time and is
cur

Split out a more generic debugnet(4) from netdump(4)

Debugnet is a simplistic and specialized panic- or debug-time reliable
datagram transport. It can drive a single connection at a time and is
currently unidirectional (debug/panic machine transmit to remote server
only).

It is mostly a verbatim code lift from netdump(4). Netdump(4) remains
the only consumer (until the rest of this patch series lands).

The INET-specific logic has been extracted somewhat more thoroughly than
previously in netdump(4), into debugnet_inet.c. UDP-layer logic and up, as
much as possible as is protocol-independent, remains in debugnet.c. The
separation is not perfect and future improvement is welcome. Supporting
INET6 is a long-term goal.

Much of the diff is "gratuitous" renaming from 'netdump_' or 'nd_' to
'debugnet_' or 'dn_' -- sorry. I thought keeping the netdump name on the
generic module would be more confusing than the refactoring.

The only functional change here is the mbuf allocation / tracking. Instead
of initiating solely on netdump-configured interface(s) at dumpon(8)
configuration time, we watch for any debugnet-enabled NIC for link
activation and query it for mbuf parameters at that time. If they exceed
the existing high-water mark allocation, we re-allocate and track the new
high-water mark. Otherwise, we leave the pre-panic mbuf allocation alone.
In a future patch in this series, this will allow initiating netdump from
panic ddb(4) without pre-panic configuration.

No other functional change intended.

Reviewed by: markj (earlier version)
Some discussion with: emaste, jhb
Objection from: marius
Differential Revision: https://reviews.freebsd.org/D21421

show more ...

Merge ^/head r340918 through r341763.

mlx4en: Add support for receiving all data using one or more MCLBYTES sized mbufs.
Also when the MTU is greater than MCLBYTES.

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

mlx4en: Add support for receiving all data using one or more MCLBYTES sized mbufs.
Also when the MTU is greater than MCLBYTES.

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

show more ...

mlx4en: Add support for netdump.

Implement the needed callback functions and support for polling the driver.

Differential Revision: https://reviews.freebsd.org/D15259
Approved by: hselasky (ment

mlx4en: Add support for netdump.

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

show more ...

mlx4en: Remove the DRBR and associated logic in the transmit path.

The hardware queues are deep enough currently and using the DRBR and associated
callbacks only leads to more task switching in the

mlx4en: Remove the DRBR and associated logic in the transmit path.

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

show more ...

mlx4: Remove redundant declarations to fix GCC build

These were made redundant in r325841.

Reviewed by: hselasky
MFC after: 1 week (hselasky will MFC)
Sponsored by: Dell EMC Isilon
Differential Rev

mlx4: Remove redundant declarations to fix GCC build

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

show more ...

Merge ^/head r325663 through r325841.

Update the mlx4 core and mlx4en(4) modules towards Linux v4.9.

Background:
The coming ibcore update forces an update of mlx4ib(4) which in turn requires
an updated mlx4 core module. This also affect

Update the mlx4 core and mlx4en(4) modules towards Linux v4.9.

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

show more ...

Merge ^/head r323559 through r325504.

MFhead@r324482

Implement SIOCGIFRSS{KEY,HASH} for the mlx4en(4) driver.

Differential Revision: https://reviews.freebsd.org/D12176
MFC after: 1 week
Sponsored by: Mellanox Technologies

MFhead@r322451

Merge ^/head r321383 through r322397.

Fix for mlx4en(4) to properly call m_defrag().

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 usin

Fix for mlx4en(4) to properly call m_defrag().

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

show more ...

MFhead@r321970

MFhead@r321829

Remove some dead statistics related code and a structure field from the
mlx4en driver which is used by its Linux counterpart, but not under
FreeBSD.

Sponsored by: Mellanox Technologies
MFC after: 1

Remove some dead statistics related code and a structure field from the
mlx4en driver which is used by its Linux counterpart, but not under
FreeBSD.

Sponsored by: Mellanox Technologies
MFC after: 1 week

show more ...

Merge ^/head r317503 through r317807.

Don't free uninitialized sysctl contexts in the mlx4en driver. This
can cause NULL pointer panics during failed device attach.

Differential Revision: https://reviews.freebsd.org/D8876
MFC after: 1

Don't free uninitialized sysctl contexts in the mlx4en driver. This
can cause NULL pointer panics during failed device attach.

Differential Revision: https://reviews.freebsd.org/D8876
MFC after: 1 week
Sponsored by: Mellanox Technologies

show more ...

Merge ^/head r306412 through r306905.