Synopsis: [arp] arp issue
State-Changed-From-To: open->closed
State-Changed-By: araujo
State-Changed-When: Wed Feb 6 07:47:52 UTC 2013
State-Changed-Why:
It was a reply to another PR. :D
http://www.freebsd.org/cgi/query-pr.cgi?pr=171728
___
freebsd-net
2013/2/6 Sami Halabi
> Hi,
> Is there explaination somewhere what ix carpdev, benefits snd usage? I
> googled, an endex on mailinv listz nog describing but bringing carpdev frkm
> open/net bsd.
>
> Thanks in advance,
> Sami
>
>
Hello,
Well, the patch was based on this revision on HEAD:
http://sv
Hi,
Is there explaination somewhere what ix carpdev, benefits snd usage? I
googled, an endex on mailinv listz nog describing but bringing carpdev frkm
open/net bsd.
Thanks in advance,
Sami
On Feb 6, 2013 5:44 AM, "Marcelo Araujo" wrote:
> Hello all,
>
> Based on all changes made by glebius@, I m
Hello all,
Based on all changes made by glebius@, I made a patch to bring to
9.1-RELEASE the capability to have the carpdev.
This patch will not be submitted to 9-STABLE! This is not my intention.
As I need carpdev on 9.1-RELEASE, I made it and now I want share with you
guys. It works properly f
Synopsis: [re] Intel MB D510MO, onboard ethernet not working after update to
9.1 [regression]
Responsible-Changed-From-To: freebsd-bugS->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Wed Feb 6 01:57:30 UTC 2013
Responsible-Changed-Why:
er, forgot to reassign.
http://www.
On Tuesday, February 05, 2013 12:44:27 pm Andre Oppermann wrote:
> On 05.02.2013 18:11, John Baldwin wrote:
> > On Wednesday, January 30, 2013 12:26:17 pm Andre Oppermann wrote:
> >> You can simply create your own congestion control algorithm with only the
> >> restart window changed. See (pseudo)
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
On 05.02.2013 18:11, John Baldwin wrote:
On Wednesday, January 30, 2013 12:26:17 pm Andre Oppermann wrote:
You can simply create your own congestion control algorithm with only the
restart window changed. See (pseudo) code below. BTW, I just noticed that
the other cc algos don't do not reset t
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
On Wednesday, January 30, 2013 12:26:17 pm Andre Oppermann wrote:
> You can simply create your own congestion control algorithm with only the
> restart window changed. See (pseudo) code below. BTW, I just noticed that
> the other cc algos don't do not reset the idle window.
*sigh* I am fully co
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
Hi all,
I applied patch on em driver code and I want to check how it is working on
different situations. I need to put some output in different parts of the
code to trace what's going on in different situations.
I've tried to write to files or executing commands(like echo) using system
function, b
Old Synopsis: in_cksum_hdr() behaves differently on amd64 vs i386 with
unaligned data
New Synopsis: [amd64] [patch] in_cksum_hdr() behaves differently on amd64 vs
i386 with unaligned data
Responsible-Changed-From-To: freebsd-amd64->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-
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
24 matches
Mail list logo
