On Fri, 29 Sep 2006, Andre Oppermann wrote:
The patch is available here:
http://people.freebsd.org/~andre/sosend+m_uiotombuf-20060928.diff
I like the concept of these changes in principle -- this is the reason I broke
out sosend_copyin(), so that we could start plugging bits of the send rout
Hi,
Is there a document discussing the implementation of SACK in freeBSD TCPIP
stack?? I am going through the code and have a few doubts regarding certain
aspects of the code.
thanks,
Chiri
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.
Srini vasa wrote:
Hi,
Is there a document discussing the implementation of SACK in freeBSD TCPIP
stack?? I am going through the code and have a few doubts regarding certain
aspects of the code.
We don't have a document detailing SACK in FreeBSD. If you have any questions
or bug reports please
Bruce,
On Wed, Sep 27, 2006 at 09:56:31PM +, Bruce M Simpson wrote:
B> Synopsis: [if_tun] "ping: sendto: No buffer space available" with TUN
interface (easily reproducable with test program)
B>
B> State-Changed-From-To: feedback->suspended
B> State-Changed-By: bms
B> State-Changed-When: We
Gleb Smirnoff wrote:
You didn't took it from free pool, but from me, w/o informing
me about it before. Okay. Now, you gave up on the PR quite
quickly, why aren't you returning it back to me?
Sorry! I have been trying to push forward on things and the PR formerly
being assigned to you got lo
Bruce,
On Fri, Sep 29, 2006 at 12:30:29PM +0100, Bruce M. Simpson wrote:
B> >You kept the PR in feedback state for 11 hours, and then you
B> >suspend the PR! Are you expecting our users to reply immediately?
B> >
B> The user responded saying they could not reproduce the problem further
B> as
Robert Watson wrote:
On Fri, 29 Sep 2006, Andre Oppermann wrote:
The patch is available here:
http://people.freebsd.org/~andre/sosend+m_uiotombuf-20060928.diff
I like the concept of these changes in principle -- this is the reason I
broke out sosend_copyin(), so that we could start plugging
On Fri, 29 Sep 2006, Andre Oppermann wrote:
I like the concept of these changes in principle -- this is the reason I
broke out sosend_copyin(), so that we could start plugging bits of the send
routines more easily for optimization. However, I think we need to review
this really carefully. A
On Friday 29 September 2006 13:35, Gleb Smirnoff wrote:
> Bruce,
>
> On Fri, Sep 29, 2006 at 12:30:29PM +0100, Bruce M. Simpson wrote:
> B> >You kept the PR in feedback state for 11 hours, and then you
> B> >suspend the PR! Are you expecting our users to reply immediately?
> B> >
> B> The user re
Mike Silbersack wrote:
On Fri, 29 Sep 2006, Andre Oppermann wrote:
over it an copies the data into the mbufs by using uiomove(). sosend_dgram()
and sosend_generic() are change to use m_uiotombuf() instead of sosend_copyin().
Can you do some UDP testing with 512b, 1K, 2K, 4K, 8K, and 16K pa
Randall Stewart wrote:
Mike Silbersack wrote:
On Fri, 29 Sep 2006, Andre Oppermann wrote:
over it an copies the data into the mbufs by using uiomove().
sosend_dgram()
and sosend_generic() are change to use m_uiotombuf() instead of
sosend_copyin().
Can you do some UDP testing with 512b, 1K
On Fri, 29 Sep 2006, Randall Stewart wrote:
> Hmm.. I would think 512b and 1K will not show any
> improvement.. since they would probably end up either
> in an mbuf chain.. or a single 2k (or maybe 4k) cluster..
I know, I just want to make sure that it doesn't somehow cause performance
loss for
Mike Silbersack wrote:
On Fri, 29 Sep 2006, Randall Stewart wrote:
Hmm.. I would think 512b and 1K will not show any
improvement.. since they would probably end up either
in an mbuf chain.. or a single 2k (or maybe 4k) cluster..
I know, I just want to make sure that it doesn't somehow cause
Randall Stewart wrote this message on Fri, Sep 29, 2006 at 16:55 -0400:
> Mike Silbersack wrote:
> >On Fri, 29 Sep 2006, Andre Oppermann wrote:
> >
> >
> >>over it an copies the data into the mbufs by using uiomove().
> >>sosend_dgram()
> >>and sosend_generic() are change to use m_uiotombuf() ins
John-Mark Gurney wrote:
IMO it's quite a waste of memory the way we have thigns now, though
w/ TSO it'll change things...
w/ 512 byte mbuf and a 2k cluster just to store just 1514 bytes of data,
I did not know we were at 512 byte mbufs.. I thought they were
256 bytes.. of course I have not che
John-Mark Gurney wrote:
Randall Stewart wrote this message on Fri, Sep 29, 2006 at 16:55 -0400:
Mike Silbersack wrote:
On Fri, 29 Sep 2006, Andre Oppermann wrote:
over it an copies the data into the mbufs by using uiomove().
sosend_dgram()
and sosend_generic() are change to use m_uiotomb
Andre,
I meant to ask: Did you try 16KB jumbos? Did they perform
any better than page-sized jumbos?
Also, if we're going to change how mbufs work, let's add something
like Linux's skb_frag_t frags[MAX_SKB_FRAGS]; In FreeBSD parlence,
this embeds something like an array of sf_bufs pointers in m
Andre Oppermann wrote:
John-Mark Gurney wrote:
mbufs are 256 bytes.
Thats what I had thought :-)
Hmmm.. If we switched clusters to 1536 bytes in size, we'd be able to
fit 8 in 12k (though I guess for 8k page boxes we'd do 16 in 24k)... The
only issue w/ that would be that a few of the clus
Andrew Gallatin wrote:
Andre,
I meant to ask: Did you try 16KB jumbos? Did they perform
any better than page-sized jumbos?
No, I didn't try 16K jumbos. The problem with anything larger than
page size is that it may look contigous in kernel memory but isn't
in physical memory. Thus you need
Andre Oppermann writes:
> Andrew Gallatin wrote:
> > Andre,
> >
> > I meant to ask: Did you try 16KB jumbos? Did they perform
> > any better than page-sized jumbos?
>
> No, I didn't try 16K jumbos. The problem with anything larger than
> page size is that it may look contigous in kerne
On 9/29/06, Andrew Gallatin <[EMAIL PROTECTED]> wrote:
Andre Oppermann writes:
> Andrew Gallatin wrote:
> > Andre,
> >
> > I meant to ask: Did you try 16KB jumbos? Did they perform
> > any better than page-sized jumbos?
>
> No, I didn't try 16K jumbos. The problem with anything larger t
Andre Oppermann wrote this message on Fri, Sep 29, 2006 at 23:59 +0200:
> >w/ 512 byte mbuf and a 2k cluster just to store just 1514 bytes of data,
> >that's only 60% effeciency wrt to memory usage... so, we currently
> >waste 40% of memory allocated to mbufs+clusters... Even reducing
> >mbufs ba
Andrew Gallatin wrote:
Andre Oppermann writes:
> Andrew Gallatin wrote:
> > Andre,
> >
> > I meant to ask: Did you try 16KB jumbos? Did they perform
> > any better than page-sized jumbos?
>
> No, I didn't try 16K jumbos. The problem with anything larger than
> page size is that it m
John-Mark Gurney wrote:
Andre Oppermann wrote this message on Fri, Sep 29, 2006 at 23:59 +0200:
w/ 512 byte mbuf and a 2k cluster just to store just 1514 bytes of data,
that's only 60% effeciency wrt to memory usage... so, we currently
waste 40% of memory allocated to mbufs+clusters... Even r
John-Mark Gurney wrote:
Andre Oppermann wrote this message on Fri, Sep 29, 2006 at 23:59 +0200:
Just don't overengineer the stuff. Mbufs are only used temporarily and
a bit theoretical waste is not much a problem (so far at least).
Well, I beg to differ... most gige cards grab mbuf+cluster fo
25 matches
Mail list logo
