<feed xmlns='http://www.w3.org/2005/Atom'>
<title>src-test/sys/dev/mlx4, branch main</title>
<subtitle>FreeBSD source tree</subtitle>
<id>https://cgit-dev.freebsd.org/src-test/atom?h=main</id>
<link rel='self' href='https://cgit-dev.freebsd.org/src-test/atom?h=main'/>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src-test/'/>
<updated>2020-11-10T12:58:25Z</updated>
<entry>
<title>Include GID type when deleting GIDs from HW table under RoCE in mlx4ib.</title>
<updated>2020-11-10T12:58:25Z</updated>
<author>
<name>Hans Petter Selasky</name>
<email>hselasky@FreeBSD.org</email>
</author>
<published>2020-11-10T12:58:25Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src-test/commit/?id=6c43a5e9c77a6265b4aaf1988f5444fc5696c0e6'/>
<id>urn:sha1:6c43a5e9c77a6265b4aaf1988f5444fc5696c0e6</id>
<content type='text'>
Refer to the Linux commit mentioned below for a more detailed description.

Linux commit:
a18177925c252da7801149abe217c05b80884798

Requested by:	Isilon
MFC after:	1 week
Sponsored by:	Mellanox Technologies // NVIDIA Networking
</content>
</entry>
<entry>
<title>Infiniband clients must be attached and detached in a specific order in ibcore.</title>
<updated>2020-07-06T08:50:11Z</updated>
<author>
<name>Hans Petter Selasky</name>
<email>hselasky@FreeBSD.org</email>
</author>
<published>2020-07-06T08:50:11Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src-test/commit/?id=1866c98e64d654649d6e134c20e3e6db7823915d'/>
<id>urn:sha1:1866c98e64d654649d6e134c20e3e6db7823915d</id>
<content type='text'>
Currently the linking order of the infiniband, IB, modules decide in which
order the clients are attached and detached. For example one IB client may
use resources from another IB client. This can lead to a potential deadlock
at shutdown. For example if the ipoib is unregistered after the ib_multicast
client is detached, then if ipoib is using multicast addresses a deadlock may
happen, because ib_multicast will wait for all its resources to be freed before
returning from the remove method.

Fix this by using module_xxx_order() instead of module_xxx().

Differential Revision:	https://reviews.freebsd.org/D23973
MFC after:		1 week
Sponsored by:		Mellanox Technologies
</content>
</entry>
<entry>
<title>Allow multicast packets to be received in promiscious mode, in mlx4en(4).</title>
<updated>2020-06-17T11:12:10Z</updated>
<author>
<name>Hans Petter Selasky</name>
<email>hselasky@FreeBSD.org</email>
</author>
<published>2020-06-17T11:12:10Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src-test/commit/?id=a26df270c96102bc9d9ba43e208207d08026cf7c'/>
<id>urn:sha1:a26df270c96102bc9d9ba43e208207d08026cf7c</id>
<content type='text'>
Make sure we disable the multicast filter in promiscious mode aswell as when
the all multicast flag is set.

MFC after:	1 week
Found by:	Tycho Nightingale &lt;tychon@freebsd.org&gt;
Sponsored by:	Mellanox Technologies
</content>
</entry>
<entry>
<title>Avoid trying to toggle TSO twice</title>
<updated>2020-06-15T16:35:27Z</updated>
<author>
<name>Ryan Moeller</name>
<email>freqlabs@FreeBSD.org</email>
</author>
<published>2020-06-15T16:35:27Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src-test/commit/?id=cbb9ccf735e9d58e2f986408b368fac5654bd729'/>
<id>urn:sha1:cbb9ccf735e9d58e2f986408b368fac5654bd729</id>
<content type='text'>
Remove TSO from the toggle mask when automatically disabled by TXCKSUM* in
various NIC drivers.

Reviewed by:	hselasky, np, gallatin, jpaetzel
Approved by:	mav (mentor)
MFC after:	1 week
Sponsored by:	iXsystems, Inc.
Differential Revision:	https://reviews.freebsd.org/D25120
</content>
</entry>
<entry>
<title>Mark more nodes as CTLFLAG_MPSAFE or CTLFLAG_NEEDGIANT (17 of many)</title>
<updated>2020-02-26T14:26:36Z</updated>
<author>
<name>Pawel Biernacki</name>
<email>kaktus@FreeBSD.org</email>
</author>
<published>2020-02-26T14:26:36Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src-test/commit/?id=7029da5c36f2d3cf6bb6c81bf551229f416399e8'/>
<id>urn:sha1:7029da5c36f2d3cf6bb6c81bf551229f416399e8</id>
<content type='text'>
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
</content>
</entry>
<entry>
<title>Widen EPOCH(9) usage in mlx4en(4).</title>
<updated>2020-01-31T10:41:47Z</updated>
<author>
<name>Hans Petter Selasky</name>
<email>hselasky@FreeBSD.org</email>
</author>
<published>2020-01-31T10:41:47Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src-test/commit/?id=f8806d0327f211510a844226b47a69bb6887c7fc'/>
<id>urn:sha1:f8806d0327f211510a844226b47a69bb6887c7fc</id>
<content type='text'>
Make sure all receive completion callbacks are covered by the network
EPOCH(9), because this is required when calling if_input() and
ether_input() after r357012.

Convert some spaces to tabs while at it.

Sponsored by:	Mellanox Technologies
</content>
</entry>
<entry>
<title>Enter the network epoch in RX processing taskqueue.</title>
<updated>2020-01-25T00:06:18Z</updated>
<author>
<name>Gleb Smirnoff</name>
<email>glebius@FreeBSD.org</email>
</author>
<published>2020-01-25T00:06:18Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src-test/commit/?id=d35738c38d4b9dc6aa56b52ec288ff33d329ea64'/>
<id>urn:sha1:d35738c38d4b9dc6aa56b52ec288ff33d329ea64</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Split out a more generic debugnet(4) from netdump(4)</title>
<updated>2019-10-17T16:23:03Z</updated>
<author>
<name>Conrad Meyer</name>
<email>cem@FreeBSD.org</email>
</author>
<published>2019-10-17T16:23:03Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src-test/commit/?id=7790c8c1996ad89a22b8bd194a230cf23ee67f4b'/>
<id>urn:sha1:7790c8c1996ad89a22b8bd194a230cf23ee67f4b</id>
<content type='text'>
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
</content>
</entry>
<entry>
<title>Convert to if_foreach_llmaddr() KPI.</title>
<updated>2019-10-14T20:23:16Z</updated>
<author>
<name>Gleb Smirnoff</name>
<email>glebius@FreeBSD.org</email>
</author>
<published>2019-10-14T20:23:16Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src-test/commit/?id=20b26072b8a286e0c1a12f35fab3d9abf2d25806'/>
<id>urn:sha1:20b26072b8a286e0c1a12f35fab3d9abf2d25806</id>
<content type='text'>
Reviewed by:	hselasky
</content>
</entry>
<entry>
<title>Include eventhandler.h in more compilation units</title>
<updated>2019-05-21T01:18:43Z</updated>
<author>
<name>Conrad Meyer</name>
<email>cem@FreeBSD.org</email>
</author>
<published>2019-05-21T01:18:43Z</published>
<link rel='alternate' type='text/html' href='https://cgit-dev.freebsd.org/src-test/commit/?id=e12be3218a280716128879e59a469f3680b103e4'/>
<id>urn:sha1:e12be3218a280716128879e59a469f3680b103e4</id>
<content type='text'>
This was enumerated with exhaustive search for sys/eventhandler.h includes,
cross-referenced against EVENTHANDLER_* usage with the comm(1) utility.  Manual
checking was performed to avoid redundant includes in some drivers where a
common os_bsd.h (for example) included sys/eventhandler.h indirectly, but it is
possible some of these are redundant with driver-specific headers in ways I
didn't notice.

(These CUs did not show up as missing eventhandler.h in tinderbox.)

X-MFC-With:	r347984
</content>
</entry>
</feed>
