Date: Sat, 10 Aug 2002 13:08:44 -0400 (EDT) From: Andrew Gallatin <gallatin@cs.duke.edu> To: Bosko Milekic <bmilekic@unixdaemons.com> Cc: ken@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Jumbo Clusters in mb_alloc Message-ID: <15701.18588.40682.896343@grasshopper.cs.duke.edu> In-Reply-To: <20020810105644.A92823@unixdaemons.com> References: <20020809151627.A88180@unixdaemons.com> <15700.9669.885383.727182@grasshopper.cs.duke.edu> <20020809164136.A88798@unixdaemons.com> <15700.13575.470677.723138@grasshopper.cs.duke.edu> <20020810105644.A92823@unixdaemons.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Bosko Milekic writes:
>
> On Fri, Aug 09, 2002 at 05:32:55PM -0400, Andrew Gallatin wrote:
> [...]
> > bus_dmamap_load_mbuf(sc->sc_dmat, dmamap, m0,
> > BUS_DMA_WRITE|BUS_DMA_NOWAIT) != 0) {
> > MGETHDR(m, M_DONTWAIT, MT_DATA);
> >
> > Methinks its high time we adopted this interface.
>
> It's really funny that I remember implementing this for Mark Murray
> quite a while ago for crypto stuff he was then working on, and now
> just recently Sam Leffler - who's doing all the cool crypto work these
> days - also mentionned he's already ported it and using it - and on
> top of it, you've ported it and are using it! - yet, we still haven't
I've not ported it... I just have some similar code which does
roughly the same thing. If I'd have thought to look at NetBSD, I'd
have "ported" it, but I didn't ;)
Note that the if_gem driver, used on the sparc64 port has its own copy
of this code that it uses.
> really merged our efforts. :-) I agree that we absolutely need this
> interface and it should know how to deal with both a chain of mbufs
> with regular clusters as well as a chain/or single mbuf with [a] jumbo
> cluster[s].
I think a good first step would be to import something ASAP and
default it to the direct interface (assume dma_addr == vtop(vaddr),
and let the various platforms adopt it as they will. I'd certainly
be happy to help with alpha, and a few drivers.
> > > What about the send case, though? How do you want to determine
> >
> > The send case opens a huge can-of-worms. Lets say that somebody is
> > forwarding between myrinet & GigE using FreeBSD, with myri0 on the
> > myrinet network, and em0 on GigE. Let's assume that myri0 is using
> > jumbo buffers, but em0 isn't jumbo aware & cannot accept them & the
> > forwarded packets end up as garbage.
> >
> > Perhaps we need to add an IFCAP_JUMBOAWARE flag and somwhere
> > (IF_DEQUE?) add a KASSERT to catch situaions like this.
> > Or even.. ick, add code to copy to a normal mbuf chain.
>
> Wow, I had not even thought of that, actually. My concern was how we
> were going to deal with things like sendto() which currently allocate
> regular clusters. In some cases, it would be advantageous for them to
> allocate the jumbo clusters if the outgoing interface supports them.
I absolutely agree.
> Anyway, the forwarding example you bring up is at least equally
> interesting. I suppose that for these [hopefully rare] cases we could
> perform a copy. Although, I have a question: is it possible to
> somehow "peek" at the data to see if it is a packet that we're
> forwarding to an interface that isn't IFCAP_JUMBOAWARE and, if so,
> just DMA into a chain of mbufs with regular clusters?
No, because by the time you can read header & see where the packet is
going, you've already setup the DMA into the jumbobuf. Heck, you've
already finished it. Besides, routes can change.
What might work, aside from data-copying, is aliasing a normal mbuf
chain (where nothing crosses a page boundary) to the jumbo buf. If
you're headed out a non IFCAP_JUMBOAWARE interface, then use the
normal alias. Otherwise, use the jumbo buf.
I'm not sure how to do this alias though..
Drew
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?15701.18588.40682.896343>