Bosko Milekic writes:
>
> Yeah, this looks like the least-intrusive way to do it. I'm okay with
> the patch. I like the idea of using an EXT-type flag to mark the data
> buffer types using this method. Thanks.
Thanks.. Committed.
> P.S.: Try not to use MEXTADD, if possible. Use
On Thu, Jan 02, 2003 at 03:47:46PM -0500, Andrew Gallatin wrote:
> > To be honest, I don't really like the idea but I don't see a better
> > solution. Right now, ref counting for regular mbuf clusters works
> > fine and is pretty damn fast, but I don't know how I could make it
> > hap
Bosko Milekic writes:
>
> On Thu, Jan 02, 2003 at 01:53:53PM -0500, Andrew Gallatin wrote:
> > I'm just tuning up my driver now to catch up to the "recent" interface
> > changes. While there, I went to add a ref count for my driver managed
> > M_EXT clusters. However, m_extadd() does not t
On Thu, Jan 02, 2003 at 01:53:53PM -0500, Andrew Gallatin wrote:
> I'm just tuning up my driver now to catch up to the "recent" interface
> changes. While there, I went to add a ref count for my driver managed
> M_EXT clusters. However, m_extadd() does not take a parameter for
> assignment into
Bosko Milekic writes:
>
> On Mon, Nov 25, 2002 at 08:13:46PM -0500, Andrew Gallatin wrote:
> > > It is not out of date. The code means:
> > >
> > > "If you've given me a counter then I'll use it otherwise I'll try to
> > > allocate one with malloc()."
> >
> > Ah, duh. Thanks
> On Mon, Nov 25, 2002 at 10:46:00AM -0800, Sam Leffler wrote:
> > > > I don't see this problem; looutput looks to do the right thing.
FWIW
> > I've
> > > > passed mbufs w/ mtags through the loopback interface.
> > >
> > > This refers specifically to the following code snippet:
> > >
> > >
On Wed, 27 Nov 2002, Julian Elischer wrote:
> On Wed, 27 Nov 2002, Robert Watson wrote:
>
> > I'd like to continue to explore options for reducing the number of memory
> > allocations to extend storage on mbufs. One idea I've been tossing around
> > is adopting Jeff Roberson's extension model u
On Wed, 27 Nov 2002, Bosko Milekic wrote:
>
> On Wed, Nov 27, 2002 at 12:51:27PM -0800, Julian Elischer wrote:
> > true.. if it has a 'size' argument it would do what I was thinkng
> > about..
>
> We actually do have that in the new m_getm(). If you do a m_getm() it
> allows you to specif
On Wed, Nov 27, 2002 at 12:51:27PM -0800, Julian Elischer wrote:
> true.. if it has a 'size' argument it would do what I was thinkng
> about..
We actually do have that in the new m_getm(). If you do a m_getm() it
allows you to specify 'size' and it will allocate a packet header mbuf
for yo
Andrew Gallatin wrote:
> If you're a vendor of a device which inserts MAC mtags and needs
> options MAC, you put this code in your driver:
>
> if (mbstat.m_mhlen != MHLEN) {
>printf("Please rebuild your kernel with 'options MAC'\n");
>goto atach_failed_no_mac;
> }
>
> I've already got cod
Terry Lambert writes:
> Andrew Gallatin wrote:
> > Terry Lambert writes:
> > > Andrew Gallatin wrote:
> > > > What I (as a 3rd party driver author working in a GNUish
>
> "This is how I do it."
>
> > <...>
> >
> > > > How is one supposed to build a 3rd party module these days?
>
On Wed, 27 Nov 2002, Bosko Milekic wrote:
>
> On Wed, Nov 27, 2002 at 11:56:33AM -0800, Julian Elischer wrote:
> > On Wed, 27 Nov 2002, Robert Watson wrote:
> > > I'd like to continue to explore options for reducing the number of memory
> > > allocations to extend storage on mbufs. One idea I'
Andrew Gallatin wrote:
> Terry Lambert writes:
> > Andrew Gallatin wrote:
> > > What I (as a 3rd party driver author working in a GNUish
"This is how I do it."
> <...>
>
> > > How is one supposed to build a 3rd party module these days?
"How are you supposed to do it?"
> > One is not. The
On Wed, Nov 27, 2002 at 11:56:33AM -0800, Julian Elischer wrote:
> On Wed, 27 Nov 2002, Robert Watson wrote:
> > I'd like to continue to explore options for reducing the number of memory
> > allocations to extend storage on mbufs. One idea I've been tossing around
> > is adopting Jeff Roberson's
Terry Lambert writes:
> Andrew Gallatin wrote:
> > What I (as a 3rd party driver author working in a GNUish
<...>
> > How is one supposed to build a 3rd party module these days?
>
> One is not. The vendor supplies only a binary.
Damn it Terry, I AM the vendor. Somtimes I wonder if you
Andrew Gallatin wrote:
> What I (as a 3rd party driver author working in a GNUish
> autoconf/gnumake environment) do is to require a user building from
> source to specify the location of a configured kernel tree where make
> depend has been run (defaulting to GENERIC). I then pickup the
> various
On Wed, 27 Nov 2002, Robert Watson wrote:
>
> I'd like to continue to explore options for reducing the number of memory
> allocations to extend storage on mbufs. One idea I've been tossing around
> is adopting Jeff Roberson's extension model used in struct proc and
> related structures.
I've
Robert Watson writes:
>
> Andrew,
>
> Thanks for your patience as I finished some research and experimentation
> regarding the options there. Some more details below.
>
> On Sat, 23 Nov 2002, Andrew Gallatin wrote:
>
> > On the contrary, I think that if anything is going to be done,
Andrew,
Thanks for your patience as I finished some research and experimentation
regarding the options there. Some more details below.
On Sat, 23 Nov 2002, Andrew Gallatin wrote:
> On the contrary, I think that if anything is going to be done, it must
> be done now, so as to not break binary n
On Mon, Nov 25, 2002 at 08:13:46PM -0500, Andrew Gallatin wrote:
> > It is not out of date. The code means:
> >
> > "If you've given me a counter then I'll use it otherwise I'll try to
> > allocate one with malloc()."
>
> Ah, duh. Thanks. I'd better start providing one in my driver
Bosko Milekic writes:
> > back. We'll also need a kproc that can wake up every now and then to
> > expand the pool if allocations at interrupt time failed. Or do you
> > already have a mechanism for that?
>
> The intended mechanism is the kproc and when the allocator was first
> des
Bosko Milekic writes:
>
> Well, first of all, I never call kmem_malloc() with any locks held so
> this argument about grabbing Giant while other locks are held is not
> applicable in my case.
Well, not for the mbuf allocator itself, but for its consumers.
> Given that you call the
Bosko Milekic wrote:
[ ... memory allocator ... ]
FWIW: The Sequent Dynix allocator paper has been converted, and
is now available online:
Experience With an Efficient Parallel Kernel Memory Allocator
Paul E. McKenney, Jack Slingwine, Phil Krueger
Sequent Computer Systems,
On Mon, Nov 25, 2002 at 04:20:39PM -0500, Andrew Gallatin wrote:
> I'm not sure what you mean. The problem is that Giant inhibits
> scaling on SMPs and I want to get all network drivers out from under
> it, not just mine.
>
> Requiring Giant for mbuf allocations effectivly defeats your elegant,
Bosko Milekic wrote:
[ ... packet size distribution ... ]
> I am equally curious about this. One of the design assumptions for
> mbufs and clusters, according to McKusick et al. (and I believe
> another text which currently escapes me) is that packets are typically
> either very small or f
Bosko Milekic wrote:
> This is not entirely true. You can allocate an mbuf chain without
> holding Giant if the caches are well populated - and they should be
> in the common/general case. You can in fact modify the allocator to
> just not do a kmem_malloc() if called with M_DONTWAIT, but
On Mon, Nov 25, 2002 at 10:46:00AM -0800, Sam Leffler wrote:
> > > I don't see this problem; looutput looks to do the right thing. FWIW
> I've
> > > passed mbufs w/ mtags through the loopback interface.
> >
> > This refers specifically to the following code snippet:
> >
> > if (m && m->m_
In message <[EMAIL PROTECTED]>, Andrew Gallatin
writes:
>I'm not sure what you mean. The problem is that Giant inhibits
>scaling on SMPs and I want to get all network drivers out from under
>it, not just mine.
Well, that is the 1' view.
Once you try to move code out from under Giant you wi
Bosko Milekic writes:
> Firstly, it should be noted that the behavior of calling kmem_malloc()
> when its caches are empty is an old property that has been carried
> over from the original allocator - in other words, it is not something
> that I arbitrarily introduced.
Certainly. I'
On Mon, Nov 25, 2002 at 01:27:39PM -0500, Andrew Gallatin wrote:
> Bosko Milekic writes:
> > On Sun, Nov 24, 2002 at 04:23:33PM -0500, Andrew Gallatin wrote:
> > > If we're going to nitpick the mbuf system, a much, much worse problem
> > > is that you cannot allocate an mbuf chain w/o holding G
> > I don't see this problem; looutput looks to do the right thing. FWIW
I've
> > passed mbufs w/ mtags through the loopback interface.
>
> This refers specifically to the following code snippet:
>
> if (m && m->m_next != NULL && m->m_pkthdr.len < MCLBYTES) {
> struct mbuf
On Mon, Nov 25, 2002 at 01:39:02PM -0500, Andrew Gallatin wrote:
...
> > widely used (at list now) thus failing the two main important criteria
on a side note i notice my english is getting worse and worse, and
i keep making mistakes as the one above. Sorry about that.
P
On Mon, 25 Nov 2002, Sam Leffler wrote:
> I don't see this problem; m_getcl appears to do the right thing.
Hmm. I see the SLIST initialization there also. Maybe I'm thinking of
another function, I'll have to go check. Sorry about that.
Robert N M Watson FreeBSD Core Team, Truste
On Mon, 25 Nov 2002, Sam Leffler wrote:
> As I explained to you; the handling of mtags mimics what was there for
> the aux mbufs. I did this intentionally to avoid changes that might
> introduce subtle problems. My intent was to cleanup this stuff after
> 5.0 releases by replacing the pkthdr co
Luigi Rizzo writes:
> The mbuf bloat has two aspects -- first it does have some cost to
> initialize and reset all these extra fields (and it is bug prone --
> witness is the missing cleanup in m_getcl(), because m-tags were
> introduced after m_getcl() and probably it was forgotten); second,
On Mon, 25 Nov 2002, Bosko Milekic wrote:
> On Mon, Nov 25, 2002 at 11:31:39AM -0500, Robert Watson wrote:
> > BTW, do you have any recent large-scale measurements of packet size
> > distribution? In local tests and measurements, the additional 20 bytes on
> > i386 didn't bump the remaining mbuf
> (1) When packet headers are copied using m_copy_pkthdr(), different
> consumers have different expectations for what the resulting semantics
> are for m_tag data -- some want it duplicated, others want it moved.
> In practice, it is only ever moved, so consumers that expect
> dupl
Bosko Milekic writes:
>
> On Sun, Nov 24, 2002 at 04:23:33PM -0500, Andrew Gallatin wrote:
> > If we're going to nitpick the mbuf system, a much, much worse problem
> > is that you cannot allocate an mbuf chain w/o holding Giant, which
> > stems from the mbuf system eventually calling kmem_m
On Mon, Nov 25, 2002 at 11:31:39AM -0500, Robert Watson wrote:
> BTW, do you have any recent large-scale measurements of packet size
> distribution? In local tests and measurements, the additional 20 bytes on
> i386 didn't bump the remaining mbuf data space sufficiently low to
> substantially cha
On Sun, Nov 24, 2002 at 01:33:29PM -0800, Julian Elischer wrote:
>
>
> On Sun, 24 Nov 2002, Andrew Gallatin wrote:
>
> >
> > If we're going to nitpick the mbuf system, a much, much worse problem
> > is that you cannot allocate an mbuf chain w/o holding Giant, which
> > stems from the mbuf syst
On Sun, Nov 24, 2002 at 04:23:33PM -0500, Andrew Gallatin wrote:
> If we're going to nitpick the mbuf system, a much, much worse problem
> is that you cannot allocate an mbuf chain w/o holding Giant, which
> stems from the mbuf system eventually calling kmem_malloc(). This
> effectively prevents
In message <[EMAIL PROTECTED]>, Robe
rt Watson writes:
>
>On Sat, 23 Nov 2002, Andrew Gallatin wrote:
>
>> I propose that we make struct label portion of the pkthdr compile-time
>> conditional on MAC. The assumption is that you will move the MAC label
>> to an m_tag sometime after 5.0-RELEASE.
I
On Mon, Nov 25, 2002 at 11:31:39AM -0500, Robert Watson wrote:
...
> This weekend I spent about six hours looking at what it would take to move
> MAC label data into m_tags. While in theory it is a workable idea, it
> turns out our m_tag implementation is fairly far from being ready to
> handle so
On Sat, 23 Nov 2002, Andrew Gallatin wrote:
> I propose that we make struct label portion of the pkthdr compile-time
> conditional on MAC. The assumption is that you will move the MAC label
> to an m_tag sometime after 5.0-RELEASE.
This weekend I spent about six hours looking at what it would
On Sun, 24 Nov 2002, Andrew Gallatin wrote:
>
> If we're going to nitpick the mbuf system, a much, much worse problem
> is that you cannot allocate an mbuf chain w/o holding Giant, which
> stems from the mbuf system eventually calling kmem_malloc(). This
> effectively prevents any network driv
Julian Elischer writes:
>
>
> On Sat, 23 Nov 2002, Andrew Gallatin wrote:
>
> >
> > As you eloquently state, there are a number of tradeoffs involved. On
> > a 64-bit platform, 99% of users are paying 40 bytes/pkt for something
> > that they will never use. On x86, 99.99% of users ar
On Sat, 23 Nov 2002, Andrew Gallatin wrote:
>
> As you eloquently state, there are a number of tradeoffs involved. On
> a 64-bit platform, 99% of users are paying 40 bytes/pkt for something
> that they will never use. On x86, 99.99% of users are paying 20
> bytes/pkt for a feature they will n
Robert Watson writes:
>
> On Thu, 21 Nov 2002, Luigi Rizzo wrote:
<...>
> > The label is 5 ints, the pkthdr a total of 11 ints (and m_hdr takes
> > another 6, for a total of 136 bytes of header info on 64-bit
> > architectures).
> >
> > Of the pkthdr, only 3 fields (rcvif, len, tags) a
On 22-Nov-2002 Robert Watson wrote:
>
> On Thu, 21 Nov 2002, Luigi Rizzo wrote:
>
>> [Bcc to -net because it is relevant there. This email has been triggered
>> by a private discussion i was having with other committers (who will
>> easily recognise themselves :) which suggested the possibility
On Thu, 21 Nov 2002, Luigi Rizzo wrote:
> [Bcc to -net because it is relevant there. This email has been triggered
> by a private discussion i was having with other committers (who will
> easily recognise themselves :) which suggested the possibility of adding
> more fields to mbuf headers]
>
>
Luigi Rizzo wrote:
> Now that Sam has done the excellent work of integrating packet tags
> to carry annotations around, i really believe that we should try
> to move out of the pkthdr all non-general fields, and move them to
> m_tags so we only pay the cost when needed and not in all cases.
> Also
Luigi Rizzo wrote:
>
> [Bcc to -net because it is relevant there. This email has been
> triggered by a private discussion i was having with other committers
> (who will easily recognise themselves :) which suggested the
> possibility of adding more fields to mbuf headers]
>
> Just recently came u
52 matches
Mail list logo
