Re: kern/168294: [ixgbe] [patch] ixgbe driver compiled in kernel has no Flow Director support although loaded as a module has one
Synopsis: [ixgbe] [patch] ixgbe driver compiled in kernel has no Flow Director support although loaded as a module has one State-Changed-From-To: open->patched State-Changed-By: maxim State-Changed-When: Sat Jun 2 13:19:59 UTC 2012 State-Changed-Why: jfv@ has committed the patch, see r235920. http://www.freebsd.org/cgi/query-pr.cgi?pr=168294 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
bin/102701 - ifconfig xx0 inet6 delete always fails
Is there any reason that this patch hasn't been applied to -current? I've just run into this and I can't believe that it still exists, given that it falls into the "low hanging fruit" category. I'll note that if it wasn't for subversion, I'd be doing a commit rather than an email. Darren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/167768: [ipfilter] Fatal trap in ipfilter/ipnat
The following reply was made to PR kern/167768; it has been noted by GNATS. From: Marc Albers To: bug-follo...@freebsd.org, bsd...@bospaling.nl Cc: Subject: Re: kern/167768: [ipfilter] Fatal trap in ipfilter/ipnat Date: Sat, 2 Jun 2012 19:30:48 +0200 switching the external (re0) and internal (em0) interfaces does not = help. Still the same kernel panic.= ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: bin/102701 - ifconfig xx0 inet6 delete always fails
On 2. Jun 2012, at 15:53 , Darren Reed wrote: > Is there any reason that this patch hasn't been applied > to -current? I've just run into this and I can't believe > that it still exists, given that it falls into the "low > hanging fruit" category. I'll note that if it wasn't for > subversion, I'd be doing a commit rather than an email. ifconfig [-L] [-k] [-m] [-n] interface [create] address_family [address [dest_address]] [parameters] ... The following parameters may be set with ifconfig: ... -alias Remove the network address specified. This would be used if you incorrectly specified an alias, or it was no longer needed. If you have incorrectly set an NS address having the side effect of specifying the host portion, removing all NS addresses will allow you to respecify the host portion. ... delete Another name for the -alias parameter. Parameters go last as clearly stated in the beginning of the man page and that works well: root@lion3:/home/test # ifconfig lo0 inet6 2001:db8:::/128 alias root@lion3:/home/test # ifconfig lo0 inet6 2001:db8:::/128 delete root@lion3:/home/test # The fact that for inet you could give it in the beginning and other minor things leniently allowed have caused a lot of trouble the last years. We try to stay more strict even if there's no real grammar, even if it wasn't for SVN. /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: bin/102701 - ifconfig xx0 inet6 delete always fails
On 3/06/2012 5:11 AM, Bjoern A. Zeeb wrote: > > On 2. Jun 2012, at 15:53 , Darren Reed wrote: > >> Is there any reason that this patch hasn't been applied >> to -current? I've just run into this and I can't believe >> that it still exists, given that it falls into the "low >> hanging fruit" category. I'll note that if it wasn't for >> subversion, I'd be doing a commit rather than an email. > > ifconfig [-L] [-k] [-m] [-n] interface [create] address_family [address > [dest_address]] [parameters] > ... > > > The following parameters may be set with ifconfig: > ... > -alias Remove the network address specified. This would be used if you > incorrectly specified an alias, or it was no longer needed. If > you have incorrectly set an NS address having the side effect of > specifying the host portion, removing all NS addresses will allow > you to respecify the host portion. > ... > delete Another name for the -alias parameter. > > > Parameters go last as clearly stated in the beginning of the man page and > that works well: > > root@lion3:/home/test # ifconfig lo0 inet6 2001:db8:::/128 alias > root@lion3:/home/test # ifconfig lo0 inet6 2001:db8:::/128 delete > root@lion3:/home/test # > > > The fact that for inet you could give it in the beginning and other minor > things leniently allowed have caused a lot of trouble the last years. This also works: ifconfig lo0 inet6 alias 2001:db8:::/128 ... so it seems strange for delete to not also work like that. Anyway, if the current behaviour isn't a bug and that PR won't be fixed (or the patch won't be applied) then someone should close it out. Darren ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Major performance hit with ToS setting
On Fri, Jun 1, 2012 at 2:48 AM, Lawrence Stewart wrote:
> On 05/31/12 13:33, Kevin Oberman wrote:
> [snip]
>>
>> I used SIFTR at the suggestion of Lawrence Stewart who headed the
>>
>> project to bring plugable congestion algorithms to FreeBSD and found
>> really odd congestion behavior. First, I do see a triple ACK, but the
>> congestion window suddenly drops from 73K to 8K. If I understand
>> CUBIC, it should half the congestion window, not what is happening..
>> It then increases slowly (in slow start) to 82K. while the slow-start
>> bytes are INCREASING, the congestion window again goes to 8K while the
>> SS size moves from 36K up to 52K. It just continues to bound wildly
>> between 8K (always the low point) and between 64k and 82K. The swings
>> start at 83K and, over the first few seconds the peaks drop to about
>> 64K.
>
>
> Oh, and a comment about this behaviour. Dropping back to 8k (1MSS) is only
> nasty if the TF_{CONG|FAST}RECOVERY flags are *not* set i.e. if you see cwnd
> grow, drop to 8k with those flags set, and then when the flags are unset,
> cwnd starts at the value of ssthresh, then that is perfectly normal recovery
> behaviour. What *is* nasty is if an RTO fires, which will reset cwnd to 8k,
> ssthresh to 2*MSS and make the connection effectively start from scratch
> again.
>
> There is evidence of RTOs in your siftr output, which is bad news e.g here's
> one example of 2 side-by-side log lines from your trace:
>
> # Direction,time,ssthresh,cwnd,flags
> i,1338319593.574706,27044,27044,1630544864
> o,1338319593.831482,16384,8192,1092625377
>
> Note the 300ms gap, and how cwnd resets to 1MSS and flags go from 1630544864
> (TF_WASCRECOVERY|TF_CONGRECOVERY|TF_WASFRECOVERY|TF_FASTRECOVERY) to
> 1092625377 (TF_WASCRECOVERY|TF_WASFRECOVERY).
What can I say but that you are right. When I looked at the interface
stats I found that the link overflow drops were through the roof! This
confuses me a bit since the traffic is outbound and I woudl assume
from the description on hte Myricom web page that these are input
drops. A problem a problem with that card? On systems that are
working "normally", I still see a sharp drop with the ToS bits set,
but nothing nearly as drastic. Now it is a drop from 4.5G to 728M on a
cross-country (US) circuit.
I am now looking for issues on the route that might explain the
performance, but the question of why the drop-of only shows up in
FreeBSD 8 means something odd is still going on. It is even possible
that the problem is with 7 and the losses are due to the policy for
ToS 32 on the path. ToS 32 is less than best effort in our network.
Maybe the marking was getting lost on 7. Not likely, but possible.
I'll post further details after some very careful reviews of router statistics.
Thanks, Lawrence!
--
R. Kevin Oberman, Network Engineer
E-mail: kob6...@gmail.com
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
