On Mon, Oct 15, 2001 at 11:35:51 -0700, Terry Lambert wrote:
> "Kenneth D. Merry" wrote:
[ ... ]
> > > This is actually very bad: you want to drop packets before you
> > > insert them into the queue, rather than after they are in the
> > > queue. This is because you want the probability of the dr
"Kenneth D. Merry" wrote:
> Dropping packets before they get into card memory would only be possible
> with some sort of traffic shaper/dropping mechanism on the wire to drop
> things before they get to the card at all.
Actually, DEC had a congestion control mechanism that worked by
marking all p
On Thu, Oct 11, 2001 at 01:02:09 -0700, Terry Lambert wrote:
> "Kenneth D. Merry" wrote:
> > If the receive ring for that packet size is full, it will hold off on
> > DMAs. If all receive rings are full, there's no reason to send more
> > interrupts.
>
> I think that this does nothing, in the Fr
"Kenneth D. Merry" wrote:
> If the receive ring for that packet size is full, it will hold off on
> DMAs. If all receive rings are full, there's no reason to send more
> interrupts.
I think that this does nothing, in the FreeBSD case, since the
data from the card will generally be drained much f
On Wed, Oct 10, 2001 at 01:59:48 -0700, Terry Lambert wrote:
> "Kenneth D. Merry" wrote:
> > eh? The card won't write past the point that has been acked by the kernel.
> > If the kernel hasn't acked the packets and one of the receive rings fills
> > up, the card will hold off on sending packets u
"Kenneth D. Merry" wrote:
> eh? The card won't write past the point that has been acked by the kernel.
> If the kernel hasn't acked the packets and one of the receive rings fills
> up, the card will hold off on sending packets up to the kernel.
Uh, eh?
You mean the card will hold off on DMA and
On Tue, Oct 09, 2001 at 12:28:02 -0700, Terry Lambert wrote:
> "Kenneth D. Merry" wrote:
> [ ... soft interrupt coelescing ... ]
>
> > As you say above, this is actually a good thing. I don't see how this ties
> > into the patch to introduce some sort of interrupt coalescing into the
> > ti(4) d
"Kenneth D. Merry" wrote:
[ ... soft interrupt coelescing ... ]
> As you say above, this is actually a good thing. I don't see how this ties
> into the patch to introduce some sort of interrupt coalescing into the
> ti(4) driver. IMO, you should be able to tweak the coalescing parameters
> on
* Mike Smith <[EMAIL PROTECTED]> [011009 00:25] wrote:
> > * Kenneth D. Merry <[EMAIL PROTECTED]> [011009 00:11] wrote:
> > >
> > > As you say above, this is actually a good thing. I don't see how this ties
> > > into the patch to introduce some sort of interrupt coalescing into the
> > > ti(4)
On Tue, Oct 09, 2001 at 00:18:57 -0500, Alfred Perlstein wrote:
> * Kenneth D. Merry <[EMAIL PROTECTED]> [011009 00:11] wrote:
> >
> > As you say above, this is actually a good thing. I don't see how this ties
> > into the patch to introduce some sort of interrupt coalescing into the
> > ti(4) d
> * Kenneth D. Merry <[EMAIL PROTECTED]> [011009 00:11] wrote:
> >
> > As you say above, this is actually a good thing. I don't see how this ties
> > into the patch to introduce some sort of interrupt coalescing into the
> > ti(4) driver. IMO, you should be able to tweak the coalescing paramet
* Kenneth D. Merry <[EMAIL PROTECTED]> [011009 00:11] wrote:
>
> As you say above, this is actually a good thing. I don't see how this ties
> into the patch to introduce some sort of interrupt coalescing into the
> ti(4) driver. IMO, you should be able to tweak the coalescing parameters
> on t
On Sun, Oct 07, 2001 at 00:56:44 -0700, Terry Lambert wrote:
> "Kenneth D. Merry" wrote:
> > [ I don't particularly want to get involved in this thread...but... ]
> >
> > Can you explain why the ti(4) driver needs a coalescing patch? It already
> > has in-firmware coalescing paramters that are t
"Kenneth D. Merry" wrote:
> [ I don't particularly want to get involved in this thread...but... ]
>
> Can you explain why the ti(4) driver needs a coalescing patch? It already
> has in-firmware coalescing paramters that are tuneable by the user. It
> also already processes all outstanding BDs i
14 matches
Mail list logo
