Good idea…
I will commit this late today.. just in case there are any trailing comments ;-)
R
On Feb 5, 2013, at 3:52 PM, John Baldwin wrote:
> On Tuesday, February 05, 2013 2:30:36 pm Randall Stewart wrote:
>> Ok
>>
>> Here it is one last time (I hope) with the updates ;-)
>
> One more sugge
Thanks for being the critical eye John :) And I appreciate the work
Randall, thanks!
Jack
On Tue, Feb 5, 2013 at 12:52 PM, John Baldwin wrote:
> On Tuesday, February 05, 2013 2:30:36 pm Randall Stewart wrote:
> > Ok
> >
> > Here it is one last time (I hope) with the updates ;-)
>
> One more su
On Tuesday, February 05, 2013 2:30:36 pm Randall Stewart wrote:
> Ok
>
> Here it is one last time (I hope) with the updates ;-)
One more suggestion. I would make the check in buf_ring_putback_sc() a
KASSERT() so that in the production case we don't pay for a branch that should
never occur.
--
Ok
Here it is one last time (I hope) with the updates ;-)
R
Index: dev/e1000/if_em.c
===
--- dev/e1000/if_em.c (revision 246357)
+++ dev/e1000/if_em.c (working copy)
@@ -905,22 +905,24 @@ em_mq_start_locked(struct ifnet *ifp, st
On Tuesday, February 05, 2013 2:08:15 pm Randall Stewart wrote:
> Hmm
>
> wait, I could probably do the compare to whats in the ring buffer ;-D
I wouldn't bother. The compare and branch is probably more expensive than
the store.
> R
> On Feb 5, 2013, at 2:04 PM, Randall Stewart wrote:
>
> > Hm
On Tuesday, February 05, 2013 2:04:12 pm Randall Stewart wrote:
> Hmm
>
> That would trade off a stack pointer + a compare
> vs always doing the move.
Right, the store is probably cheaper than the branch. :) However, minimizing
the duplicated code in drivers and having this interface be as clea
Hmm
wait, I could probably do the compare to whats in the ring buffer ;-D
R
On Feb 5, 2013, at 2:04 PM, Randall Stewart wrote:
> Hmm
>
> That would trade off a stack pointer + a compare
> vs always doing the move.
>
> Thats fine until I have to add the _mc() version, then the put
> back would
Hmm
That would trade off a stack pointer + a compare
vs always doing the move.
Thats fine until I have to add the _mc() version, then the put
back would be an atomic, and most of the time the return from
this is probably not changed…
I really would prefer not to since the compare and maybe store
On Tuesday, February 05, 2013 12:44:01 pm Randall Stewart wrote:
> Actually, no it is used.
>
> If you look in if_var.h int he drbr_putback() function, it does
> a buf_ring_swap when the old mbuf pointer does not equal the
> new mbuf pointer. This *does* happen, I crashed at least once
> yesterday
On Tuesday, February 05, 2013 12:44:01 pm Randall Stewart wrote:
> Actually, no it is used.
>
> If you look in if_var.h int he drbr_putback() function, it does
> a buf_ring_swap when the old mbuf pointer does not equal the
> new mbuf pointer. This *does* happen, I crashed at least once
> yesterday
Actually, no it is used.
If you look in if_var.h int he drbr_putback() function, it does
a buf_ring_swap when the old mbuf pointer does not equal the
new mbuf pointer. This *does* happen, I crashed at least once
yesterday when the igb driver did something to free the original
mbuf and return a new
On Tuesday, February 05, 2013 10:24:24 am Randall Stewart wrote:
> Here is an updated patch… sigh.. I foobar'd the ALTQ stuff.. lots of crashes
;-D
Heh, I like this better, thanks. I think you can remove buf_ring_swap() as it
is no longer used?
--
John Baldwin
Here is an updated patch… sigh.. I foobar'd the ALTQ stuff.. lots of crashes ;-D
R
Index: dev/e1000/if_em.c
===
--- dev/e1000/if_em.c (revision 246357)
+++ dev/e1000/if_em.c (working copy)
@@ -894,7 +894,7 @@ static int
em_mq_s
John:
Here is an updated patch, per your suggestions. Note that I also
expanded and the only driver that uses these methods I did not touch
is the cxgb, but thats because I am not really sure it has the problem… it
does not quite enqueue the same way (it appears) that the other drivers do ;-)
R
On Feb 4, 2013, at 3:24 PM, John Baldwin wrote:
> On Monday, February 04, 2013 12:22:49 pm Randy Stewart wrote:
>> All:
>>
>> I have been working with TCP in gigabit networks (igb driver actually) and
>> have
>> found a very nasty problem with the way the driver is doing its put back when
>> it
On Monday, February 04, 2013 12:22:49 pm Randy Stewart wrote:
> All:
>
> I have been working with TCP in gigabit networks (igb driver actually) and
> have
> found a very nasty problem with the way the driver is doing its put back when
> it fills the out-bound transmit queue.
>
> Basically it has
I am beating the heck out of it on my 9.x testbed where I lifted it from.
I don't have any ix or ixgbe cards to play with yet though..
R
On Feb 4, 2013, at 1:11 PM, Jack Vogel wrote:
>
>
> On Mon, Feb 4, 2013 at 9:22 AM, Randy Stewart wrote:
> All:
>
> I have been working with TCP in gigabit
On Mon, Feb 4, 2013 at 9:22 AM, Randy Stewart wrote:
> All:
>
> I have been working with TCP in gigabit networks (igb driver actually) and
> have
> found a very nasty problem with the way the driver is doing its put back
> when
> it fills the out-bound transmit queue.
>
> Basically it has taken a
All:
I have been working with TCP in gigabit networks (igb driver actually) and have
found a very nasty problem with the way the driver is doing its put back when
it fills the out-bound transmit queue.
Basically it has taken a packet from the head of the ring buffer, and then
realizes it can't f
19 matches
Mail list logo
