Differential D1987

Factor out MBUF hashing code for Ethernet and TCP/IP.
AbandonedPublic
Actions

Authored by • hselasky on Feb 28 2015, 4:19 PM.

Tags

None

Referenced Files

	Unknown Object (File)
	Fri, Mar 7, 6:56 AM

	Unknown Object (File)
	Feb 22 2025, 2:03 PM

	Unknown Object (File)
	Feb 21 2025, 12:07 PM

	Unknown Object (File)
	Feb 21 2025, 11:06 AM

	Unknown Object (File)
	Feb 14 2025, 10:04 PM

	Unknown Object (File)
	Feb 3 2025, 9:06 PM

	Unknown Object (File)
	Jan 30 2025, 10:03 AM

	Unknown Object (File)
	Jan 30 2025, 9:20 AM

Subscribers

None

Details

Reviewers

ken
ae
glebius
adrian

Summary

Factor out mbuf hashing code instead of copying it around.

Diff Detail

Lint

Lint Skipped

Unit

Tests Skipped

Event Timeline

Add full patch context.

Factor out more code.

Remove patches not belonging to this issue.

• hselasky set the repository for this revision to rS FreeBSD src repository - subversion.Feb 28 2015, 7:41 PM

Update patch to latest FreeBSD-11 code and fix some build issues.

Get the directory layout correct.

Build fix.

• hselasky added a reviewer: ae.Mar 3 2015, 11:00 AM

• hselasky set the repository for this revision to rS FreeBSD src repository - subversion.

ae added a reviewer: network.Mar 3 2015, 12:10 PM

ae removed a subscriber: Unknown Object (MLST).

It looks like adrian@ already has added number of constants to define hash types in mbuf.h. And there are a lot of room to define other types. Are you sure that it is necessary to add also mask for them?

sys/kern/uipc_mbufhash.c
54	Missing an empty line.
98	"When declaring variables in functions declare them sorted by size, then in alphabetical order; multiple ones per line are okay." (c) style(9) :)

Address comments from ae @

style(9) compliancy

This patch also adds hashing of "ip6_flow" under MBUF_HASHFLAG_L4, which I consider to be a shortcut for hashing the source and destination ports.

Ping: Anyone planning to give this patch a go or no-go in the near future?

jmg removed a reviewer: network.Mar 5 2015, 6:32 PM

It looks like adrian@ already has added number of constants to define hash types in mbuf.h. And
there are a lot of room to define other types. Are you sure that it is necessary to add also mask for
them?

The hash flags added don't have anything to do with the hash types.

I don't need to add a hash mask.

--HPS

Remove hash mask. Add missing locking in if_lagg.

Committed to FreeBSD-head in r279891.

Revision Contents
Changeset List

Path

Size

sys/

conf/

1 line

kern/

uipc_mbufhash.c

125 lines

modules/

mlxen/

2 lines

net/

ieee8023ad_lacp.c

8 lines

1 line

142 lines

ofed/

drivers/

net/

mlx4/

7 lines

44 lines

189 lines

sys/

10 lines

Diff 4082

sys/conf/files

Context not available.

	JAVA="%%LOCALBASE%%/bin/java"			JAVA="%%LOCALBASE%%/bin/java"
	JARPATH="%%JAVALIBDIR%%"			JARPATH="%%JAVALIBDIR%%"
	export JAVA_VERSION="%%JAVA_VERSION%%"
	glewisUnsubmitted Not Done Inline Actions Note that this may cause a subtle change in behaviour if either the ports tree is not present on a system or if javavmwrapper is otherwise instructed to use it's own internal logic (e.g. if JAVAVM_FALLBACK_ONLY is set). > env JAVAVM_FALLBACK_ONLY=yes JAVA_VERSION=1.6+ /usr/local/bin/java -version openjdk version "12.0.2" 2019-07-16 > env JAVAVM_FALLBACK_ONLY=yes /usr/local/bin/java -version openjdk version "13.0.1" 2019-10-15 This will depend on what versions the user has installed. This is actually more of a bug in javavmwrapper which I'll look into (it doesn't understand JDK 13 yet). It also doesn't have a default version (e.g. 8) and uses the "newest" one if no version is supplied. If a version is supplied then it uses the newest version that it understands. An alternative to all these script changes would be to have bsd.java.mk always add JAVA_VERSION to SUB_LIST, using the version it ends up deciding on if none is set. glewis: Note that this may cause a subtle change in behaviour if either the ports tree is not present…
	jkimAuthorUnsubmitted Not Done Inline Actions AFAIK, the inconsistency with JAVAVM_FALLBACK_ONLY is intentional. Actually, the manual page says: However, this option, when used with scripts installed by a port, may result in Java VM selection inconsistent with that intended by the script author. jkim: AFAIK, the inconsistency with JAVAVM_FALLBACK_ONLY is intentional. Actually, the manual page…
	glewisUnsubmitted Not Done Inline Actions As the author of javavmwrapper, it is certainly the case that when using JAVAVM_FALLBACK_ONLY that you may get different behaviour from what you do when the ports tree is present. What is a bug is that the presence of "JAVA_VERSION=1.6+" in the two command lines above shouldn't make a difference. Whether it is present or not, the fallback logic should choose the same version. That is what I was pointing out. So by removing that line from the invocation, this change may affect what version is chosen in that situation, even though it shouldn't. The likelihood of this impacting people is quite low though, so I'm not overly concerned. I also have a fix I can commit after this change (I don't want to commit while this is in flight since it will conflict with changes here). glewis: As the author of javavmwrapper, it is certainly the case that when using JAVAVM_FALLBACK_ONLY…
	jkimAuthorUnsubmitted Not Done Inline Actions Understood. Yes, it looks like there's a bug in javavmwrapper. It should not show any difference with or without the ports tree as the PR167799 said. jkim: Understood. Yes, it looks like there's a bug in javavmwrapper. It should not show any…

	exec "${JAVA}" -jar "${JARPATH}/%%JARNAME%%" "$@"			exec "${JAVA}" -jar "${JARPATH}/%%JARNAME%%" "$@"
Context not available.

sys/kern/uipc_mbufhash.c

Context not available.

	JAVA="%%LOCALBASE%%/bin/java"			JAVA="%%LOCALBASE%%/bin/java"
	JARPATH="%%JAVALIBDIR%%"			JARPATH="%%JAVALIBDIR%%"
	export JAVA_VERSION="%%JAVA_VERSION%%"
	glewisUnsubmitted Not Done Inline Actions Note that this may cause a subtle change in behaviour if either the ports tree is not present on a system or if javavmwrapper is otherwise instructed to use it's own internal logic (e.g. if JAVAVM_FALLBACK_ONLY is set). > env JAVAVM_FALLBACK_ONLY=yes JAVA_VERSION=1.6+ /usr/local/bin/java -version openjdk version "12.0.2" 2019-07-16 > env JAVAVM_FALLBACK_ONLY=yes /usr/local/bin/java -version openjdk version "13.0.1" 2019-10-15 This will depend on what versions the user has installed. This is actually more of a bug in javavmwrapper which I'll look into (it doesn't understand JDK 13 yet). It also doesn't have a default version (e.g. 8) and uses the "newest" one if no version is supplied. If a version is supplied then it uses the newest version that it understands. An alternative to all these script changes would be to have bsd.java.mk always add JAVA_VERSION to SUB_LIST, using the version it ends up deciding on if none is set. glewis: Note that this may cause a subtle change in behaviour if either the ports tree is not present…
	jkimAuthorUnsubmitted Not Done Inline Actions AFAIK, the inconsistency with JAVAVM_FALLBACK_ONLY is intentional. Actually, the manual page says: However, this option, when used with scripts installed by a port, may result in Java VM selection inconsistent with that intended by the script author. jkim: AFAIK, the inconsistency with JAVAVM_FALLBACK_ONLY is intentional. Actually, the manual page…
	glewisUnsubmitted Not Done Inline Actions As the author of javavmwrapper, it is certainly the case that when using JAVAVM_FALLBACK_ONLY that you may get different behaviour from what you do when the ports tree is present. What is a bug is that the presence of "JAVA_VERSION=1.6+" in the two command lines above shouldn't make a difference. Whether it is present or not, the fallback logic should choose the same version. That is what I was pointing out. So by removing that line from the invocation, this change may affect what version is chosen in that situation, even though it shouldn't. The likelihood of this impacting people is quite low though, so I'm not overly concerned. I also have a fix I can commit after this change (I don't want to commit while this is in flight since it will conflict with changes here). glewis: As the author of javavmwrapper, it is certainly the case that when using JAVAVM_FALLBACK_ONLY…
	jkimAuthorUnsubmitted Not Done Inline Actions Understood. Yes, it looks like there's a bug in javavmwrapper. It should not show any difference with or without the ports tree as the PR167799 said. jkim: Understood. Yes, it looks like there's a bug in javavmwrapper. It should not show any…

	exec "${JAVA}" -jar "${JARPATH}/%%JARNAME%%" "$@"			exec "${JAVA}" -jar "${JARPATH}/%%JARNAME%%" "$@"
Context not available.

sys/modules/mlxen/Makefile

Context not available.

	JAVA="%%LOCALBASE%%/bin/java"			JAVA="%%LOCALBASE%%/bin/java"
	JARPATH="%%JAVALIBDIR%%"			JARPATH="%%JAVALIBDIR%%"
	export JAVA_VERSION="%%JAVA_VERSION%%"
	glewisUnsubmitted Not Done Inline Actions Note that this may cause a subtle change in behaviour if either the ports tree is not present on a system or if javavmwrapper is otherwise instructed to use it's own internal logic (e.g. if JAVAVM_FALLBACK_ONLY is set). > env JAVAVM_FALLBACK_ONLY=yes JAVA_VERSION=1.6+ /usr/local/bin/java -version openjdk version "12.0.2" 2019-07-16 > env JAVAVM_FALLBACK_ONLY=yes /usr/local/bin/java -version openjdk version "13.0.1" 2019-10-15 This will depend on what versions the user has installed. This is actually more of a bug in javavmwrapper which I'll look into (it doesn't understand JDK 13 yet). It also doesn't have a default version (e.g. 8) and uses the "newest" one if no version is supplied. If a version is supplied then it uses the newest version that it understands. An alternative to all these script changes would be to have bsd.java.mk always add JAVA_VERSION to SUB_LIST, using the version it ends up deciding on if none is set. glewis: Note that this may cause a subtle change in behaviour if either the ports tree is not present…
	jkimAuthorUnsubmitted Not Done Inline Actions AFAIK, the inconsistency with JAVAVM_FALLBACK_ONLY is intentional. Actually, the manual page says: However, this option, when used with scripts installed by a port, may result in Java VM selection inconsistent with that intended by the script author. jkim: AFAIK, the inconsistency with JAVAVM_FALLBACK_ONLY is intentional. Actually, the manual page…
	glewisUnsubmitted Not Done Inline Actions As the author of javavmwrapper, it is certainly the case that when using JAVAVM_FALLBACK_ONLY that you may get different behaviour from what you do when the ports tree is present. What is a bug is that the presence of "JAVA_VERSION=1.6+" in the two command lines above shouldn't make a difference. Whether it is present or not, the fallback logic should choose the same version. That is what I was pointing out. So by removing that line from the invocation, this change may affect what version is chosen in that situation, even though it shouldn't. The likelihood of this impacting people is quite low though, so I'm not overly concerned. I also have a fix I can commit after this change (I don't want to commit while this is in flight since it will conflict with changes here). glewis: As the author of javavmwrapper, it is certainly the case that when using JAVAVM_FALLBACK_ONLY…
	jkimAuthorUnsubmitted Not Done Inline Actions Understood. Yes, it looks like there's a bug in javavmwrapper. It should not show any difference with or without the ports tree as the PR167799 said. jkim: Understood. Yes, it looks like there's a bug in javavmwrapper. It should not show any…

	exec "${JAVA}" -jar "${JARPATH}/%%JARNAME%%" "$@"			exec "${JAVA}" -jar "${JARPATH}/%%JARNAME%%" "$@"
Context not available.

sys/net/ieee8023ad_lacp.c

Context not available.

	JAVA="%%LOCALBASE%%/bin/java"			JAVA="%%LOCALBASE%%/bin/java"
	JARPATH="%%JAVALIBDIR%%"			JARPATH="%%JAVALIBDIR%%"
	export JAVA_VERSION="%%JAVA_VERSION%%"
	glewisUnsubmitted Not Done Inline Actions Note that this may cause a subtle change in behaviour if either the ports tree is not present on a system or if javavmwrapper is otherwise instructed to use it's own internal logic (e.g. if JAVAVM_FALLBACK_ONLY is set). > env JAVAVM_FALLBACK_ONLY=yes JAVA_VERSION=1.6+ /usr/local/bin/java -version openjdk version "12.0.2" 2019-07-16 > env JAVAVM_FALLBACK_ONLY=yes /usr/local/bin/java -version openjdk version "13.0.1" 2019-10-15 This will depend on what versions the user has installed. This is actually more of a bug in javavmwrapper which I'll look into (it doesn't understand JDK 13 yet). It also doesn't have a default version (e.g. 8) and uses the "newest" one if no version is supplied. If a version is supplied then it uses the newest version that it understands. An alternative to all these script changes would be to have bsd.java.mk always add JAVA_VERSION to SUB_LIST, using the version it ends up deciding on if none is set. glewis: Note that this may cause a subtle change in behaviour if either the ports tree is not present…
	jkimAuthorUnsubmitted Not Done Inline Actions AFAIK, the inconsistency with JAVAVM_FALLBACK_ONLY is intentional. Actually, the manual page says: However, this option, when used with scripts installed by a port, may result in Java VM selection inconsistent with that intended by the script author. jkim: AFAIK, the inconsistency with JAVAVM_FALLBACK_ONLY is intentional. Actually, the manual page…
	glewisUnsubmitted Not Done Inline Actions As the author of javavmwrapper, it is certainly the case that when using JAVAVM_FALLBACK_ONLY that you may get different behaviour from what you do when the ports tree is present. What is a bug is that the presence of "JAVA_VERSION=1.6+" in the two command lines above shouldn't make a difference. Whether it is present or not, the fallback logic should choose the same version. That is what I was pointing out. So by removing that line from the invocation, this change may affect what version is chosen in that situation, even though it shouldn't. The likelihood of this impacting people is quite low though, so I'm not overly concerned. I also have a fix I can commit after this change (I don't want to commit while this is in flight since it will conflict with changes here). glewis: As the author of javavmwrapper, it is certainly the case that when using JAVAVM_FALLBACK_ONLY…
	jkimAuthorUnsubmitted Not Done Inline Actions Understood. Yes, it looks like there's a bug in javavmwrapper. It should not show any difference with or without the ports tree as the PR167799 said. jkim: Understood. Yes, it looks like there's a bug in javavmwrapper. It should not show any…

	exec "${JAVA}" -jar "${JARPATH}/%%JARNAME%%" "$@"			exec "${JAVA}" -jar "${JARPATH}/%%JARNAME%%" "$@"
Context not available.

sys/net/if_lagg.h

Loading...

sys/net/if_lagg.c

Loading...

sys/ofed/drivers/net/mlx4/en_tx.c

Loading...

sys/ofed/drivers/net/mlx4/utils.h

Loading...

sys/ofed/drivers/net/mlx4/utils.c

Loading...

sys/sys/mbuf.h

Loading...