From owner-freebsd-net@FreeBSD.ORG Tue Nov 6 08:27:18 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 95AF3663; Tue, 6 Nov 2012 08:27:18 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 617708FC08; Tue, 6 Nov 2012 08:27:18 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi1so157652pad.13 for ; Tue, 06 Nov 2012 00:27:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=wyGVsZ/ekWk1lrfRwaiiuvXfoIN6s60I+a1eh+kqS6U=; b=P+6cZhcyNF5PM6qyWRtwQT/ErIX+T5ecSUKJtE1ifYyEhhr0BcD17UBAtAMXotm5w/ AhgAeqYhuGFy5HChkZoKV+aNEqo3i83UHgt6Xfs/hJi+uvexq2OXAZ12pX3Ihe8N8MWO +8633wJNZju5JgJaIo1QNvlDeWLEgZiKLf8D71Xw2MvPc/1ISyae9q1brbbG1Y/X32Mv by267FQZ+9Kx9ttwyyOczc+q+yrofr+hs1o9Ww3LU4Q79IWAIQWDHdru1WZMJEJo16ZR vcMjW3g/Jr12S/F7Rpg3PnAih9W7Zipq8wQZAYyNTEmgNs+3wWS/VjZCFvOkNvhQ99wu 4zMA== MIME-Version: 1.0 Received: by 10.68.247.134 with SMTP id ye6mr1188286pbc.69.1352190437860; Tue, 06 Nov 2012 00:27:17 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Tue, 6 Nov 2012 00:27:17 -0800 (PST) In-Reply-To: <20121102123817.GP70741@FreeBSD.org> References: <20121102123817.GP70741@FreeBSD.org> Date: Tue, 6 Nov 2012 00:27:17 -0800 X-Google-Sender-Auth: Z333sf_o5ulh4umGh_DXJXgGs2U Message-ID: Subject: Re: splitting m_flags to pkthdr.flags + m_flags From: Adrian Chadd To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 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: Tue, 06 Nov 2012 08:27:18 -0000 Hiya, On 2 November 2012 05: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 > 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