On 02.11.2012 13:38, Gleb Smirnoff wrote:
Hello networkers,
some (most) of m_flags bits are describing features that can
be present on a packet only, not on a single mbuf. Since we are
close to exhaustion of available bits, and many subsystems prefer
to use one of M_PROTO bits instead of grabbing a flag, I propose
The use of M_PROTO for protocol and layer specific use is very much
its intended purpose and should be kept that way with overlays. The
available range of M_PROTO can be extended with your proposed change.
M_PROTO could be split into mbuf and mbuf header flags. Most of the
time they are also only relevant on packets.
to split m_flags to two parts:
I fully agree on the split. The previous mixing of mbuf and mbuf header
flags was irritating and confusing.
In the m_flags remain:
#define M_EXT 0x00000001 /* has associated external storage */
#define M_PKTHDR 0x00000002 /* start of record */
#define M_EOR 0x00000004 /* end of record */
#define M_RDONLY 0x00000008 /* associated data is marked read-only */
and all M_PROTO flags.
struct pkthdr grows by one word and its new flag word now
posesses:
#define M_BCAST 0x00000200 /* send/received as link-level broadcast */
#define M_MCAST 0x00000400 /* send/received as link-level multicast */
#define M_FRAG 0x00000800 /* packet is a fragment of a larger packet */
#define M_FIRSTFRAG 0x00001000 /* packet is first fragment */
#define M_LASTFRAG 0x00002000 /* packet is last fragment */
I wonder if actually have any users of the M_*FRAG flags. And if yes,
if it can be solved in a different way with less flags.
#define M_SKIP_FIREWALL 0x00004000 /* skip firewall processing */
This one should become an M_PROTO overlay. It is only relevant within
a protocol layer.
#define M_VLANTAG 0x00010000 /* ether_vtag is valid */
#define M_PROMISC 0x00020000 /* packet was not for us */
#define M_FLOWID 0x00400000 /* deprecated: flowid is valid */
#define M_HASHTYPEBITS 0x0F000000 /* mask of bits holding flowid hash type */
>
Some M_PROTO abusements like M_FASTFWD_OURS and recently added M_IP_NEXTHOP
also go to the pkthdr mbuf flags.
On the contrary. This isn't abuse of M_PROTO. It's the exact pupose
of it.
P.S.
An attentive reader may have noticed that I missed M_NOFREE and M_FREELIST.
Yep, these flags coming from historical mbuf allocator from FreeBSD 4.x times
are about to be deleted, we carefully examine them, but never set. Patch
for review attached.
Looks good. Go ahead from me.
--
Andre
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
