From owner-freebsd-net@FreeBSD.ORG Fri Nov 2 12:55:03 2012 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DD004C74 for ; Fri, 2 Nov 2012 12:55:03 +0000 (UTC) (envelope-from oppermann@networx.ch) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 4BE308FC0C for ; Fri, 2 Nov 2012 12:55:02 +0000 (UTC) Received: (qmail 84993 invoked from network); 2 Nov 2012 14:31:08 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 2 Nov 2012 14:31:08 -0000 Message-ID: <5093C29A.4020902@networx.ch> Date: Fri, 02 Nov 2012 13:54:50 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Gleb Smirnoff Subject: Re: splitting m_flags to pkthdr.flags + m_flags References: <20121102123817.GP70741@FreeBSD.org> In-Reply-To: <20121102123817.GP70741@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2012 12:55:03 -0000 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