Date: Tue, 6 Nov 2012 00:27:17 -0800 From: Adrian Chadd <adrian@freebsd.org> To: Gleb Smirnoff <glebius@freebsd.org> Cc: net@freebsd.org Subject: Re: splitting m_flags to pkthdr.flags + m_flags Message-ID: <CAJ-Vmo=gqOLSo5mTwe=27EbPV71cCLiOZDNVOTttDfxT24pDQw@mail.gmail.com> In-Reply-To: <20121102123817.GP70741@FreeBSD.org> References: <20121102123817.GP70741@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hiya, On 2 November 2012 05:38, Gleb Smirnoff <glebius@freebsd.org> 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 > to split m_flags to two parts: The idea of splitting things up is nice and it does make sense. > 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 */ > #define M_SKIP_FIREWALL 0x00004000 /* skip firewall processing */ > #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. > > 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. My comments: * We don't know if any downstream clients are using M_NOFREE for whatever reason. M_FREELIST may be easy to kill but again, who knows who's reused it in their own code. So I'd prefer that this sort of thing was more widely communicated to the major (known) FreeBSD companies before you go and change this stuff. * .. I'm not sure whether you want to churn the mbuf API through some accessor API at this stage - ie, instead of just separating things out, what about also at the same time creating accessor macros that right now just go to the mbuf flags, but later on break it out to the hdr and non-hdr flags? * There's been a lot of network stack churn lately. I personally think we should wait a while longer and let the fallout .. well, finish falling out, before you continue churning things. :-) Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=gqOLSo5mTwe=27EbPV71cCLiOZDNVOTttDfxT24pDQw>