Re: [RFC] Allow m_dup() to use JUMBO clusters

John-Mark Gurney wrote:
> Hans Petter Selasky wrote this message on Mon, Jul 07, 2014 at 10:12
> +0200:
> > I'm asking for some input on the attached m_dup() patch, so that
> > existing functionality or dependencies are not broken. The
> > background
> > for the change is to allow m_dup() to defrag long mbuf chains that
> > doesn't fit into a specific hardware's scatter gather entries,
> > typically
> > when doing TSO.
> > 
> > In my case the HW limit is 16 entries of length 4K for doing a
> > 64KByte
> > TSO packet. Currently m_dup() is at best producing 32 entries of
> > each 2K
> > for a 64Kbytes TSO packet.
> > 
> > By allowing m_dup() to get JUMBO clusters when allocating mbufs, we
> > avoid creating a new function, specific to the hardware, to defrag
> > some
> > rare-occurring very long mbuf chains into a mbuf chain below 16
> > entries.
> 
> Please no... Until we get a better allocator, we should not use jumbo
> (>page sized) mbufs otherwise we will quickly fail to allocate mbufs
> after a machine has been up for a long while causing other
> failures...
> 
> Unless of course if the code fails to allocate the largest cluster it
> falls through to trying to allocate the next smaller size, that might
> be better...
> 
Unfortunately, for the "can't allocate boundary tags" case, the allocation
request with M_NOWAIT loops instead of failing.

I tried:
      m = m_getjcl(M_NOWAIT..M_JUMPAGESIZE);
      if (m == NULL)
           m = getjcl(M_WAITOK..MCLBYTES);
when I was experimenting with MJUMPAGESIZE clusters for NFS and what happened
was the thread looped in the first m_getjcl() instead of returning NULL.
It is about 12 layers of function calls deep and most fail/return NULL, but
somewhere one of them decides to "try again". I didn't locate the location
of that and don't know if it would be safe to change it so that m_getjcl()
returns NULL for this case.

rick


> --
>   John-Mark Gurney				Voice: +1 415 225 5579
> 
>      "All that I will do, has been done, All that I have, has not."
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
> "freebsd-current-unsubscribe_at_freebsd.org"
>