Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 18 May 2002 21:35:55 -0600
From:      "Kenneth D. Merry" <ken@kdm.org>
To:        John Baldwin <jhb@FreeBSD.org>
Cc:        net@FreeBSD.org, current@FreeBSD.org, Alfred Perlstein <bright@mu.org>
Subject:   Re: new zero copy sockets patches available
Message-ID:  <20020518213555.A46216@panzer.kdm.org>
In-Reply-To: <XFMail.20020518090338.jhb@FreeBSD.org>; from jhb@FreeBSD.org on Sat, May 18, 2002 at 09:03:38AM -0400
References:  <20020518003046.A36510@panzer.kdm.org> <XFMail.20020518090338.jhb@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, May 18, 2002 at 09:03:38 -0400, John Baldwin wrote:
> 
> On 18-May-2002 Kenneth D. Merry wrote:
> > On Fri, May 17, 2002 at 23:02:55 -0700, Alfred Perlstein wrote:
> >> * Kenneth D. Merry <ken@kdm.org> [020517 22:40] wrote:
> >> > 
> >> > I have released a new set of zero copy sockets patches, against -current
> >> > from today (May 17th, 2002).
> >> > 
> >> > The main change is to deal with the vfs_ioopt changes that Alan Cox made
> >> > in
> >> > kern_subr.c.  (They conflicted a bit with the zero copy receive code.)
> >> > 
> >> > The patches and the FAQ are available here:
> >> > 
> >> > http://people.freebsd.org/~ken/zero_copy/
> >> > 
> >> > Comments, questions and reviews are all welcome!
> >> 
> >> jumbo_vm_init() has a bunch of bugs
> >> 
> >> first it doesn't work right if called concurrently.
> >> you need to protect the initialization of jumbo_vm_object otherwise
> >> bad things can happen.  my suggestion is to store the results of
> >> vm_object_allocate into a temporary, grab the mutex and then check
> >> to see if jumbo_vm_object has been initialized again if it has then
> >> free the object, otherwise store the allocated object into the
> >> global and continue.
> > 
> > The problem here is that the mutex needs to be initialized before I can
> > acquire it, and there's going to be a race between checking to see
> > whether it has been initialized and actually initializing it.
> > 
> > e.g.:
> > 
> >       if (!mtx_initialized(&jumbo_mutex))
> >               mtx_init(&jumbo_mutex, "jumbo mutex", NULL, MTX_DEF);
> > 
> >       mtx_lock(&jumbo_mutex);
> > 
> >       if (jumbo_vm_object != NULL) {
> >               mtx_unlock(&jumbo_mutex);
> >               return (1);
> >       }
> > 
> >       /* allocate our object */
> >       jumbo_vm_object = vm_object_allocate(OBJT_DEFAULT, JUMBO_MAX_PAGES);
> > 
> > The above would work, I think, if it weren't for the race in the mutex
> > initialization, and assuming I can allocate a vm object while holding
> > the jumbo mutex.
> > 
> > Suggestions?
> 
> Either use a sysinit or something gross like this:
> 
>         static int jumbo_init = 0;
> 
>         ...
>         while (jumbo_init != 2) {
>                 if (atomic_cmpset_acq_int(&jumbo_init, 0, 1) {
>                         mtx_init(&jumbo_mutex, "jumbo_mutex", NULL, MTX_DEF);
>                         atomic_store_rel_int(&jumbo_init, 2);
>                 }
>         }
> 
>         mtx_lock(&jumbo_mutex);
> 
>         ...
> 
> a sysinit is probably best though.

Sounds like a sysinit is probably the way to go.

I'll give it a try, thanks!

Ken
-- 
Kenneth Merry
ken@kdm.org

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020518213555.A46216>