Re: mbuf_jumbo_9k & iSCSI failing

[Hans Petter Selasky]

On 09/22/17 22:33, Ben RUBSON wrote:

On 22 Sep 2017, at 20:48, Ryan Stone  wrote:

Hans and I have proposed different approaches to the problem.  I was
taken off this issue at $WORK for a while, but coincidentally I just
picked it up again in the last week or so.  I'm working on evaluating
the performance characteristics of the two approaches and once I'm
satisfied with that I'll work with Hans to get a solution into the
tree.


Many thanks for the update Ryan !
Good timing again on the email :)



Hi Ryan,

If I didn't send you patches for testing for JUMBO 9K and acceleration 
of small packet RX - ping me off-list.


--HPS
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: mbuf_jumbo_9k & iSCSI failing

[Ben RUBSON]

> On 22 Sep 2017, at 20:48, Ryan Stone  wrote:
> 
> Hans and I have proposed different approaches to the problem.  I was
> taken off this issue at $WORK for a while, but coincidentally I just
> picked it up again in the last week or so.  I'm working on evaluating
> the performance characteristics of the two approaches and once I'm
> satisfied with that I'll work with Hans to get a solution into the
> tree.

Many thanks for the update Ryan !
Good timing again on the email :)

Ben
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: CARP under 10.3 - can't "ifconfig down" one or more VHIDs?

[Steven Hartland]

CARP on 9 and 10 are very different its not a separate interface 
anymore, its a property on the parent interface, so the behavior your 
described is expected.


If you want to disable carp just remove it, if however you want for fail 
to the other virtual host, just bump the advskew or force the state change.


    Regards
    Steve

On 22/09/2017 14:21, Karl Pielorz wrote:


Hi,

We've been using CARP for a long time - initially under FreeBSD 9.x.

We're just looking at setting it up on some 10.3 boxes, and have hit a 
snag. Some of the syntax for setting it up has changed, but that's Ok, 
we've read up and got it working.


The issue we've got is if I want to "disable CARP" on one of the 9.x 
boxes, temporarily I can do:


 ifconfig carp0 down
 ifconfig carp1 down
 ifconfig carp2 down


The host's base NIC IP address (i.e. non-vhid) address is left usable, 
and intact - but all the CARP interfaces get set as "INIT" - so 
they're still there, but they're not going to participate in CARP, 
until you do a "ifconfig carpX up" on them.



If I try this under 10.3 - e.g. with a NIC with 3 vhid's setup:

 carp: BACKUP vhid 1 advbase 1 advskew 100
 carp: BACKUP vhid 2 advbase 1 advskew 100
 carp: BACKUP vhid 3 advbase 1 advskew 100

So, I do:

 ifconfig em0 vhid 1 down

And, they *all* go to INIT:

 carp: INIT vhid 1 advbase 1 advskew 100
 carp: INIT vhid 2 advbase 1 advskew 100
 carp: INIT vhid 3 advbase 1 advskew 100

And, worse - em0 is now also down.

Trying to set the 'state' to "INIT" on an individual vhid doesn't work 
either (no error, but it does nothing).


Is there a way under 10.3 to "disable" (i.e. set to INIT) the CARP 
vhid's - without disabling the underlying NIC?


We tend to do this for maintenance where we're taking services down, 
and don't want the host to 'accidentally' pickup stray CARP vhid's 
from other boxes (because there's no service running).


Thanks,

-Karl
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"


___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: mbuf_jumbo_9k & iSCSI failing

[Ryan Stone]

Hans and I have proposed different approaches to the problem.  I was
taken off this issue at $WORK for a while, but coincidentally I just
picked it up again in the last week or so.  I'm working on evaluating
the performance characteristics of the two approaches and once I'm
satisfied with that I'll work with Hans to get a solution into the
tree.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: mbuf_jumbo_9k & iSCSI failing

[Ben RUBSON]

> On 12 Jul 2017, at 01:02, Ryan Stone  wrote:
> 
> I've just put up a review that fixes mlx4_en to no longer use clusters larger 
> than PAGE_SIZE in its receive path.  The patch is based off of the older 
> version of the driver which did the same, but keeps all of the changes to the 
> driver since then (including support for bus_dma).  The review can be found 
> here:
> 
> https://reviews.freebsd.org/D11560 

Hi Ryan, Hans, Matt... and lists :)
May I ask you some news, did you manage to find a suitable way to solve this 
issue ?
Many thanks !
Ben
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

CARP under 10.3 - can't "ifconfig down" one or more VHIDs?

[Karl Pielorz]

Hi,

We've been using CARP for a long time - initially under FreeBSD 9.x.

We're just looking at setting it up on some 10.3 boxes, and have hit a 
snag. Some of the syntax for setting it up has changed, but that's Ok, 
we've read up and got it working.


The issue we've got is if I want to "disable CARP" on one of the 9.x boxes, 
temporarily I can do:


 ifconfig carp0 down
 ifconfig carp1 down
 ifconfig carp2 down


The host's base NIC IP address (i.e. non-vhid) address is left usable, and 
intact - but all the CARP interfaces get set as "INIT" - so they're still 
there, but they're not going to participate in CARP, until you do a 
"ifconfig carpX up" on them.



If I try this under 10.3 - e.g. with a NIC with 3 vhid's setup:

 carp: BACKUP vhid 1 advbase 1 advskew 100
 carp: BACKUP vhid 2 advbase 1 advskew 100
 carp: BACKUP vhid 3 advbase 1 advskew 100

So, I do:

 ifconfig em0 vhid 1 down

And, they *all* go to INIT:

 carp: INIT vhid 1 advbase 1 advskew 100
 carp: INIT vhid 2 advbase 1 advskew 100
 carp: INIT vhid 3 advbase 1 advskew 100

And, worse - em0 is now also down.

Trying to set the 'state' to "INIT" on an individual vhid doesn't work 
either (no error, but it does nothing).


Is there a way under 10.3 to "disable" (i.e. set to INIT) the CARP vhid's - 
without disabling the underlying NIC?


We tend to do this for maintenance where we're taking services down, and 
don't want the host to 'accidentally' pickup stray CARP vhid's from other 
boxes (because there's no service running).


Thanks,

-Karl
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] D12457: Complete INADDR_HASH lock protection

[eugen_grosbein.net (Eugene Grosbein)]

eugen_grosbein.net marked an inline comment as done.
eugen_grosbein.net added inline comments.

INLINE COMMENTS

> mav wrote in if_stf.c:383
> Wouldn't it be better to use in_localip() here instead of code duplication?  
> Or I miss something?

in_localip() may be better, I just wished to make the patch as clear as 
possible minizing changes for first revision.

REPOSITORY
  rS FreeBSD src repository

REVISION DETAIL
  https://reviews.freebsd.org/D12457

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: eugen_grosbein.net, ae, avg, mav, rwatson
Cc: bz, imp, freebsd-net-list
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] D12457: Complete INADDR_HASH lock protection

[rwatson (Robert Watson)]

rwatson added a subscriber: bz.
rwatson added a comment.


  Many of these changes are not sufficient to address the underlying problems 
in this code, as the lock covers loop iteration but fails to protect the 
stability of the 'ifp' or 'ia' pointer outside of the loop. It could be that 
this prevents the crash you are seeing as the issue is iteration over entries 
being deleted from the list, or that the problem you are seeing is masked by 
changes in timing (as it involves using an ifp, ia, etc, being removed). It 
would be useful to think a little harder about our goals here. @bz and I have 
been pondering for some time a somewhat coarser, rmlock-based synchronisation 
approach to use in these circumstances, but have not prototyped this yet.

REPOSITORY
  rS FreeBSD src repository

REVISION DETAIL
  https://reviews.freebsd.org/D12457

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: eugen_grosbein.net, ae, avg, mav, rwatson
Cc: bz, imp, freebsd-net-list
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] D12453: mbuf: Remove UDP_IPV4_EX, which is never defined.

[rwatson (Robert Watson)]

rwatson accepted this revision.
rwatson added a comment.
This revision is now accepted and ready to land.


  This seems generally sensible.
  
  I'm not quite sure about keeping the "Non-standard RSS hash types" comment, 
as M_HASHTYPE_OPAQUE is basically intended to be a catch-all for any other 
model, and is not specifically intended to be RSS (hence not having RSS in its 
name). So I'd be tempted to drop that comment.

REVISION DETAIL
  https://reviews.freebsd.org/D12453

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: sepherosa_gmail.com, rwatson, adrian, gallatin, freebsd-net-list, glebius
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] D12457: Complete INADDR_HASH lock protection

[mav (Alexander Motin)]

mav added inline comments.

INLINE COMMENTS

> if_stf.c:383
>   break;
> + IN_IFADDR_RUNLOCK(_ifa_tracker);
>   if (ia4 == NULL)

Wouldn't it be better to use in_localip() here instead of code duplication?  Or 
I miss something?

> in_mcast.c:1383
> + IN_IFADDR_RUNLOCK(_ifa_tracker);
> + }
>   if (sopt->sopt_name == IP_BLOCK_SOURCE)

Do I miss some other protection means or this and few below places just scream 
about possible races due to missing interface pointer pulled out of the lock 
without taking reference?

I suspect INADDR_TO_IFP KPI is not safe now in general.

> ip_input.c:697
>   }
> - /* IN_IFADDR_RUNLOCK(); */
> + IN_IFADDR_RUNLOCK(_ifa_tracker);
>  

Looking on r194951 commit message and later r286001 commit this should be 
uncommented now, but comments from active networking people are welcome.

REPOSITORY
  rS FreeBSD src repository

REVISION DETAIL
  https://reviews.freebsd.org/D12457

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: eugen_grosbein.net, ae, avg, mav, rwatson
Cc: imp, freebsd-net-list
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] D12457: Complete INADDR_HASH lock protection

[eugen_grosbein.net (Eugene Grosbein)]

eugen_grosbein.net created this revision.
Herald added a subscriber: imp.

REVISION SUMMARY
  If a system has dynamic ever changing set of IP addresses, it can panic due 
to unprotected access to global INADDR_HASH in several kernel subsystems: 
ip_input.c, in_mcast.c, if_stf(4).
  
  There was also similar problem in ip_fw2.c fixed recently in head by ae@.
  kgdb showed "(struct in_ifaddr *) 0xdeadc0dedeadc0de" for a panic in 
INVARIANTS-enabled kernel (PR #220078).
  
  I could provoke such panic in ipfw with my stress-test for net/mpd5 
creating/deleting hundreds of ngXXX interfaces having distinct IP addresses.
  
  Proposed change makes use of existing IN_IFADDR_[RW]LOCK macros to protect 
access to the set as they are already used in the ip_icmp.c, if_ether.c and 
in.c.

TEST PLAN
  The nature of the race makes it hard to reproduce the bug, but it can happen 
using high loaded (or stress-tested) net/mpd5 installation.
  
  1. Apply the patch.
  2. Rebuild a kernel.
  3. Run busy mpd5 server with hundreds of users reconnecting very often.

REPOSITORY
  rS FreeBSD src repository

REVISION DETAIL
  https://reviews.freebsd.org/D12457

AFFECTED FILES
  sys/net/if_stf.c
  sys/netinet/in_mcast.c
  sys/netinet/ip_input.c

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: eugen_grosbein.net, ae, avg, mav, rwatson
Cc: imp, freebsd-net-list
diff --git a/sys/net/if_stf.c.orig b/sys/net/if_stf.c
--- a/sys/net/if_stf.c.orig
+++ b/sys/net/if_stf.c
@@ -360,6 +360,7 @@
 static int
 stf_getsrcifa6(struct ifnet *ifp, struct in6_addr *addr, struct in6_addr *mask)
 {
+	struct rm_priotracker in_ifa_tracker;
 	struct ifaddr *ia;
 	struct in_ifaddr *ia4;
 	struct in6_ifaddr *ia6;
@@ -375,9 +376,11 @@
 			continue;
 
 		bcopy(GET_V4(>sin6_addr), , sizeof(in));
+		IN_IFADDR_RLOCK(_ifa_tracker);
 		LIST_FOREACH(ia4, INADDR_HASH(in.s_addr), ia_hash)
 			if (ia4->ia_addr.sin_addr.s_addr == in.s_addr)
 break;
+		IN_IFADDR_RUNLOCK(_ifa_tracker);
 		if (ia4 == NULL)
 			continue;
 
diff --git a/sys/netinet/in_mcast.c.orig b/sys/netinet/in_mcast.c
--- a/sys/netinet/in_mcast.c.orig
+++ b/sys/netinet/in_mcast.c
@@ -1338,6 +1338,7 @@
 inp_block_unblock_source(struct inpcb *inp, struct sockopt *sopt)
 {
 	struct group_source_req		 gsr;
+	struct rm_priotracker		 in_ifa_tracker;
 	sockunion_t			*gsa, *ssa;
 	struct ifnet			*ifp;
 	struct in_mfilter		*imf;
@@ -1375,9 +1376,11 @@
 		ssa->sin.sin_len = sizeof(struct sockaddr_in);
 		ssa->sin.sin_addr = mreqs.imr_sourceaddr;
 
-		if (!in_nullhost(mreqs.imr_interface))
+		if (!in_nullhost(mreqs.imr_interface)) {
+			IN_IFADDR_RLOCK(_ifa_tracker);
 			INADDR_TO_IFP(mreqs.imr_interface, ifp);
-
+			IN_IFADDR_RUNLOCK(_ifa_tracker);
+		}
 		if (sopt->sopt_name == IP_BLOCK_SOURCE)
 			doblock = 1;
 
@@ -1873,7 +1876,6 @@
  *
  * Returns NULL if no ifp could be found.
  *
- * SMPng: TODO: Acquire the appropriate locks for INADDR_TO_IFP.
  * FUTURE: Implement IPv4 source-address selection.
  */
 static struct ifnet *
@@ -1891,7 +1893,9 @@
 
 	ifp = NULL;
 	if (!in_nullhost(ina)) {
+		IN_IFADDR_RLOCK(_ifa_tracker);
 		INADDR_TO_IFP(ina, ifp);
+		IN_IFADDR_RUNLOCK(_ifa_tracker);
 	} else {
 		fibnum = inp ? inp->inp_inc.inc_fibnum : 0;
 		if (fib4_lookup_nh_basic(fibnum, gsin->sin_addr, 0, 0, )==0)
@@ -2223,6 +2227,7 @@
 {
 	struct group_source_req		 gsr;
 	struct ip_mreq_source		 mreqs;
+	struct rm_priotracker		 in_ifa_tracker;
 	sockunion_t			*gsa, *ssa;
 	struct ifnet			*ifp;
 	struct in_mfilter		*imf;
@@ -2281,9 +2286,11 @@
 		 * XXX NOTE WELL: The RFC 3678 API is preferred because
 		 * using an IPv4 address as a key is racy.
 		 */
-		if (!in_nullhost(mreqs.imr_interface))
+		if (!in_nullhost(mreqs.imr_interface)) {
+			IN_IFADDR_RLOCK(_ifa_tracker);
 			INADDR_TO_IFP(mreqs.imr_interface, ifp);
-
+			IN_IFADDR_RUNLOCK(_ifa_tracker);
+		}
 		CTR3(KTR_IGMPV3, "%s: imr_interface = 0x%08x, ifp = %p",
 		__func__, ntohl(mreqs.imr_interface.s_addr), ifp);
 
@@ -2443,6 +2450,7 @@
 static int
 inp_set_multicast_if(struct inpcb *inp, struct sockopt *sopt)
 {
+	struct rm_priotracker	 in_ifa_tracker;
 	struct in_addr		 addr;
 	struct ip_mreqn		 mreqn;
 	struct ifnet		*ifp;
@@ -2481,7 +2489,9 @@
 		if (in_nullhost(addr)) {
 			ifp = NULL;
 		} else {
+			IN_IFADDR_RLOCK(_ifa_tracker);
 			INADDR_TO_IFP(addr, ifp);
+			IN_IFADDR_RUNLOCK(_ifa_tracker);
 			if (ifp == NULL)
 return (EADDRNOTAVAIL);
 		}
diff --git a/sys/netinet/ip_input.c.orig b/sys/netinet/ip_input.c
--- a/sys/netinet/ip_input.c.orig
+++ b/sys/netinet/ip_input.c
@@ -446,6 +446,7 @@
 void
 ip_input(struct mbuf *m)
 {
+	struct rm_priotracker in_ifa_tracker;
 	struct ip *ip = NULL;
 	struct in_ifaddr *ia = NULL;
 	struct ifaddr *ifa;
@@ -677,7 +678,7 @@
 	/*
 	 * Check for exact addresses in the hash bucket.
 	 */
-	/* IN_IFADDR_RLOCK(); */
+	IN_IFADDR_RLOCK(_ifa_tracker);
 	LIST_FOREACH(ia, INADDR_HASH(ip->ip_dst.s_addr), ia_hash) {
 		/*
 		 * If the address matches, verify that the packet
@@ 

[Bug 222512] [netgraph] ng_con_nodes calls ng_findhook() on unprotected node2

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222512

Andriy Gapon  changed:

   What|Removed |Added

 CC||eu...@freebsd.org,
   ||m...@freebsd.org
   Assignee|freebsd-b...@freebsd.org|freebsd-net@FreeBSD.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 220078] [patch] [panic] [ipfw] repeatable kernel panic due to unlocked INADDR_TO_IFP usage

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220078

Eugene Grosbein  changed:

   What|Removed |Added

   Assignee|freebsd-i...@freebsd.org|eu...@freebsd.org
 CC|po...@grosbein.net  |freebsd-i...@freebsd.org
 Status|New |In Progress

--- Comment #19 from Eugene Grosbein  ---
My PR.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] D12455: rss: Remove never defined UDP_IPV4_EX

[sepherosa_gmail.com (Sepherosa Ziehau)]

sepherosa_gmail.com created this revision.
Herald added a subscriber: ae.

REVISION DETAIL
  https://reviews.freebsd.org/D12455

AFFECTED FILES
  sys/net/rss_config.c
  sys/net/rss_config.h

CHANGE DETAILS

diff --git a/sys/net/rss_config.h b/sys/net/rss_config.h
--- a/sys/net/rss_config.h
+++ b/sys/net/rss_config.h
@@ -66,7 +66,6 @@
 #defineRSS_HASHTYPE_RSS_IPV6_EX(1 << 5)/* IPv6 2-tuple 
+ ext hdrs */
 #defineRSS_HASHTYPE_RSS_TCP_IPV6_EX(1 << 6)/* TCPv6 
4-tiple + ext hdrs */
 #defineRSS_HASHTYPE_RSS_UDP_IPV4   (1 << 7)/* IPv4 UDP 
4-tuple */
-#defineRSS_HASHTYPE_RSS_UDP_IPV4_EX(1 << 8)/* IPv4 UDP 
4-tuple + ext hdrs */
 #defineRSS_HASHTYPE_RSS_UDP_IPV6   (1 << 9)/* IPv6 UDP 
4-tuple */
 #defineRSS_HASHTYPE_RSS_UDP_IPV6_EX(1 << 10)   /* IPv6 UDP 
4-tuple + ext hdrs */
 
diff --git a/sys/net/rss_config.c b/sys/net/rss_config.c
--- a/sys/net/rss_config.c
+++ b/sys/net/rss_config.c
@@ -489,7 +489,6 @@
|RSS_HASHTYPE_RSS_TCP_IPV6_EX
 #if 0
|RSS_HASHTYPE_RSS_UDP_IPV4
-   |RSS_HASHTYPE_RSS_UDP_IPV4_EX
|RSS_HASHTYPE_RSS_UDP_IPV6
|RSS_HASHTYPE_RSS_UDP_IPV6_EX
 #endif



EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: sepherosa_gmail.com, adrian, rwatson, gallatin, freebsd-net-list
Cc: ae
diff --git a/sys/net/rss_config.h b/sys/net/rss_config.h
--- a/sys/net/rss_config.h
+++ b/sys/net/rss_config.h
@@ -66,7 +66,6 @@
 #define	RSS_HASHTYPE_RSS_IPV6_EX	(1 << 5)	/* IPv6 2-tuple + ext hdrs */
 #define	RSS_HASHTYPE_RSS_TCP_IPV6_EX	(1 << 6)	/* TCPv6 4-tiple + ext hdrs */
 #define	RSS_HASHTYPE_RSS_UDP_IPV4	(1 << 7)	/* IPv4 UDP 4-tuple */
-#define	RSS_HASHTYPE_RSS_UDP_IPV4_EX	(1 << 8)	/* IPv4 UDP 4-tuple + ext hdrs */
 #define	RSS_HASHTYPE_RSS_UDP_IPV6	(1 << 9)	/* IPv6 UDP 4-tuple */
 #define	RSS_HASHTYPE_RSS_UDP_IPV6_EX	(1 << 10)	/* IPv6 UDP 4-tuple + ext hdrs */
 
diff --git a/sys/net/rss_config.c b/sys/net/rss_config.c
--- a/sys/net/rss_config.c
+++ b/sys/net/rss_config.c
@@ -489,7 +489,6 @@
 	|RSS_HASHTYPE_RSS_TCP_IPV6_EX
 #if 0
 	|RSS_HASHTYPE_RSS_UDP_IPV4
-	|RSS_HASHTYPE_RSS_UDP_IPV4_EX
 	|RSS_HASHTYPE_RSS_UDP_IPV6
 	|RSS_HASHTYPE_RSS_UDP_IPV6_EX
 #endif

___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"