On Mon, 31 Jul 2006, John Polstra wrote:
I question whether you need a fallback software if_snd queue at all
for modern devices such as the Intel and Broadcom gigabit chips. The
hardware transmit descriptor rings typically have sizes of the order
of 256 descriptors. I think if the ring fills u
Robert Watson writes:
>
> On Tue, 1 Aug 2006, Andrew Gallatin wrote:
>
> > > - The ifnet send queue is a separately locked object from the device
> > > driver,
> > >meaning that for a single enqueue/dequeue pair, we pay an extra four
> > > lock
> > >operations (two for insert,
Robert Watson writes:
>
> Jack Vogel at Intel has previously talked about having TSO patches for
> FreeBSD
> to use with if_em, but was running into stability/correctness problems on
> 7.x.
> I e-mailed him a few minutes ago to ask to take a look at the patches.
> Since
> I've not
On Tue, 1 Aug 2006, Andrew Gallatin wrote:
> - The ifnet send queue is a separately locked object from the device driver,
>meaning that for a single enqueue/dequeue pair, we pay an extra four lock
>operations (two for insert, two for remove) per packet.
Going forward, especially now th
On Tue, 1 Aug 2006, Andrew Gallatin wrote:
Robert Watson writes:
> The immediate practical benefit is clear: if the queueing at the ifnet
> layer is unnecessary, it is entirely avoided, skipping enqueue, dequeue,
> and four mutex operations.
This is indeed nice, but for TCP I think the b
Robert Watson writes:
> The immediate practical benefit is
> clear: if the queueing at the ifnet layer is unnecessary, it is entirely
> avoided, skipping enqueue, dequeue, and four mutex operations.
This is indeed nice, but for TCP I think the benefit would be far
greater if somebody wo
Robert Watson writes:
>
> 5BOne of the ideas that I, Scott Long, and a few others have been bouncing
> around for some time is a restructuring of the network interface packet
> transmission API to reduce the number of locking operations and allow
> network
> device drivers increased con
Robert Watson writes:
> tear-down magic. What Solaris does here, FYI, is basically add a lock
> around
> entering the device driver via their mac layer in order to prevent it from
> "disappearing" while in use via the ifnet interface. I'm not sure if we
> want
At least for GLDv2, this
Robert Watson wrote this message on Mon, Jul 31, 2006 at 18:08 +0100:
> >I question whether you need a fallback software if_snd queue at all for
> >modern devices such as the Intel and Broadcom gigabit chips. The hardware
> >transmit descriptor rings typically have sizes of the order of 256
> >
On 31-Jul-2006 Petri Helenius wrote:
> Robert Watson wrote:
>>
>> I tend to agree, but implemented full queueing support for if_em to
>> make sure I understood to complexity implications of completely
>> removing queueing from the ifnet side dispatch. I guess an
>> interesting question for us i
Robert Watson wrote:
I tend to agree, but implemented full queueing support for if_em to
make sure I understood to complexity implications of completely
removing queueing from the ifnet side dispatch. I guess an
interesting question for us is how we decide what the right threshold
is to imp
On Mon, 31 Jul 2006, John Polstra wrote:
Attached is a patch that maintains the current if_start, but adds
if_startmbuf. If a device driver implements if_startmbuf and the global
sysctl net.startmbuf_enabled is set to 1, then the if_startmbuf path in the
driver will be used. Otherwise, if_st
> Attached is a patch that maintains the current if_start, but adds
> if_startmbuf. If a device driver implements if_startmbuf and the global
> sysctl net.startmbuf_enabled is set to 1, then the if_startmbuf path in the
> driver will be used. Otherwise, if_start is used. I have modified the i
On Sun, 30 Jul 2006, Sam Leffler wrote:
I'm a little uncomfortable with our current m_tag model, as it requires
significant numbers of additional allocations and frees for each packet, as
well as walking link lists. It's fine for occasional discretionary use
(i.e., MAC labels), but I worry a
On Mon, 31 Jul 2006, Hans Petter Selasky wrote:
On Sunday 30 July 2006 21:23, Robert Watson wrote:
On Sun, 30 Jul 2006, Sam Leffler wrote:
Just a comment while the iron is hot:
Maybe you can make the network model safe against detach. Currently I see
that the processor can be stuck in rout
On Sunday 30 July 2006 21:23, Robert Watson wrote:
> On Sun, 30 Jul 2006, Sam Leffler wrote:
Just a comment while the iron is hot:
Maybe you can make the network model safe against detach. Currently I see that
the processor can be stuck in routines like "if_start" after that "if_free()"
has bee
Robert Watson wrote:
On Sun, 30 Jul 2006, Sam Leffler wrote:
I have a fair amount of experience with the linux model and it works
ok. The main complication I've seen is when a driver needs to process
multiple queues of packets things get more involved. This is seen in
802.11 drivers where th
At Sun, 30 Jul 2006 15:04:48 +0100 (BST),
rwatson wrote:
> Conceptual review as well as banchmarking, etc, would be most welcome.
>
I remember talking about this at BSDCan and certainly for high end
hardware it seems that it's the right way to go.
Later,
George
_
Robert Watson wrote:
On Sun, 30 Jul 2006, Sam Leffler wrote:
I have a fair amount of experience with the linux model and it works
ok. The main complication I've seen is when a driver needs to process
multiple queues of packets things get more involved. This is seen in
802.11 drivers where t
On Sun, 30 Jul 2006, Sam Leffler wrote:
I have a fair amount of experience with the linux model and it works ok.
The main complication I've seen is when a driver needs to process multiple
queues of packets things get more involved. This is seen in 802.11 drivers
where there are two q's, one f
Robert Watson wrote:
5BOne of the ideas that I, Scott Long, and a few others have been
bouncing around for some time is a restructuring of the network
interface packet transmission API to reduce the number of locking
operations and allow network device drivers increased control of the
queuei
21 matches
Mail list logo
