svn commit: r275358 - in head/sys: dev/bxe dev/cxgb dev/cxgbe dev/e1000 dev/ixgbe dev/ixl dev/mxge dev/netmap dev/oce dev/qlxgbe dev/qlxge dev/sfxge dev/virtio/network dev/vmware/vmxnet3 dev/vxge n...
John Baldwin
jhb at freebsd.org
Mon Dec 1 14:48:40 UTC 2014
On Monday, December 01, 2014 11:45:25 AM Hans Petter Selasky wrote:
> Author: hselasky
> Date: Mon Dec 1 11:45:24 2014
> New Revision: 275358
> URL: https://svnweb.freebsd.org/changeset/base/275358
>
> Log:
> Start process of removing the use of the deprecated "M_FLOWID" flag
> from the FreeBSD network code. The flag is still kept around in the
> "sys/mbuf.h" header file, but does no longer have any users. Instead
> the "m_pkthdr.rsstype" field in the mbuf structure is now used to
> decide the meaning of the "m_pkthdr.flowid" field. To modify the
> "m_pkthdr.rsstype" field please use the existing "M_HASHTYPE_XXX"
> macros as defined in the "sys/mbuf.h" header file.
>
> This patch introduces new behaviour in the transmit direction.
> Previously network drivers checked if "M_FLOWID" was set in "m_flags"
> before using the "m_pkthdr.flowid" field. This check has now now been
> replaced by checking if "M_HASHTYPE_GET(m)" is different from
> "M_HASHTYPE_NONE". In the future more hashtypes will be added, for
> example hashtypes for hardware dedicated flows.
>
> "M_HASHTYPE_OPAQUE" indicates that the "m_pkthdr.flowid" value is
> valid and has no particular type. This change removes the need for an
> "if" statement in TCP transmit code checking for the presence of a
> valid flowid value. The "if" statement mentioned above is now a direct
> variable assignment which is then later checked by the respective
> network drivers like before.
>
> Additional notes:
> - The SCTP code changes will be committed as a separate patch.
> - Removal of the "M_FLOWID" flag will also be done separately.
> - The FreeBSD version has been bumped.
>
> MFC after: 1 month
> Sponsored by: Mellanox Technologies
Was this reviewed by anyone? I know I saw at least one thread on reworking
M_FLOWID on one list, but it's not clear to me that anyone reviewed these
specific changes. If someone did, please be sure to include that type of
detail in future commits. If not, I would strongly encourage to still seek
review even if changes have been agreed upon in the abstract. Phabricator
makes this a lot easier to do than previously.
--
John Baldwin
More information about the svn-src-all
mailing list