On Tue, Aug 20, 2013 at 11:44:56PM -0700, Brendan Gregg wrote:
> G'Day,
>
> On Tue, Aug 20, 2013 at 10:00 PM, Mark Johnston wrote:
>
> > Hello!
> >
> > I've ported the ip, tcp and udp DTrace providers to FreeBSD, following
> > the Solaris documentation here:
> >
> > https://wikis.oracle.com/disp
On Wed, Aug 21, 2013 at 5:52 PM, Alan Somers wrote:
> On Wed, Aug 21, 2013 at 3:28 PM, Will Andrews wrote:
>
> When would you ever want lo0 to be inaccessible from some fibs? I can't
> think of any reasons.
>
>
I can't think of a use case either, that is why I mentioned he has my
wheels turning
On Wed, Aug 21, 2013 at 5:28 PM, Will Andrews wrote:
>
> Other places in rc.d/routing can make use of 'all' in that case.
>
> No, loopback host routes are not installed into all FIBs, only FIB 0.
> This is with rt_add_addr_allfibs == 0 (see rtinit1()), which probably
> explains why. We could add
On Wed, Aug 21, 2013 at 3:28 PM, Will Andrews wrote:
> On Wed, Aug 21, 2013 at 12:20 PM, Hiroki Sato wrote:
> > wi> * Always add loopback routes for non-zero FIBs, for both IPv4 and
> > wi> IPv6. Arguably, this could be a policy issue, but it is currently
> > wi> less-than-trivial to specify (i
On Wed, Aug 21, 2013 at 12:20 PM, Hiroki Sato wrote:
> wi> * Always add loopback routes for non-zero FIBs, for both IPv4 and
> wi> IPv6. Arguably, this could be a policy issue, but it is currently
> wi> less-than-trivial to specify (in rc.conf) that a route needs to be
> wi> applied to every FIB.
On 08/21/13 13:59, Andre Oppermann wrote:
> On 21.08.2013 22:52, Navdeep Parhar wrote:
>> It is most flexible to let M_NOFREE work without any assumptions
>> attached (must be M_EXT, etc.) So I still prefer my patch to this. If
>> you don't have any strong preferences may I commit that one inste
On 21.08.2013 22:52, Navdeep Parhar wrote:
On 08/21/13 13:44, Andre Oppermann wrote:
On 21.08.2013 21:40, Navdeep Parhar wrote:
On 08/21/13 12:22, Andre Oppermann wrote:
On 21.08.2013 20:23, Navdeep Parhar wrote:
I believe we need an extra patch to get M_NOFREE correct. I've had it
forever i
On 08/21/13 13:44, Andre Oppermann wrote:
> On 21.08.2013 21:40, Navdeep Parhar wrote:
>> On 08/21/13 12:22, Andre Oppermann wrote:
>>> On 21.08.2013 20:23, Navdeep Parhar wrote:
I believe we need an extra patch to get M_NOFREE correct. I've had it
forever in some of my internal repos bu
On 19.08.2013 13:42, Alexander V. Chernikov wrote:
On 14.08.2013 19:48, Luigi Rizzo wrote:
On Wed, Aug 14, 2013 at 05:40:28PM +0200, Marko Zec wrote:
On Wednesday 14 August 2013 14:40:24 Luigi Rizzo wrote:
On Wed, Aug 14, 2013 at 04:15:25PM +0400, Alexander V. Chernikov wrote:
...
FWIW, appa
On 21.08.2013 21:40, Navdeep Parhar wrote:
On 08/21/13 12:22, Andre Oppermann wrote:
On 21.08.2013 20:23, Navdeep Parhar wrote:
I believe we need an extra patch to get M_NOFREE correct. I've had it
forever in some of my internal repos but never committed it upstream
(just plain forgot). Since
On 08/21/13 12:22, Andre Oppermann wrote:
> On 21.08.2013 20:23, Navdeep Parhar wrote:
>> I believe we need an extra patch to get M_NOFREE correct. I've had it
>> forever in some of my internal repos but never committed it upstream
>> (just plain forgot). Since this stuff is fresh in your mind, c
On 21.08.2013 20:23, Navdeep Parhar wrote:
I believe we need an extra patch to get M_NOFREE correct. I've had it
forever in some of my internal repos but never committed it upstream
(just plain forgot). Since this stuff is fresh in your mind, can you
review this:
diff -r cd78031b7885 sys/sys/m
I'd like to add a last-active timestamp to the structure that tracks the
LRO state in a NIC's rx handler. This is r254336 in user/np/cxl_tuning
that will be merged to head if there are no objections.
http://svnweb.freebsd.org/base?view=revision&revision=254336
http://svnweb.freebsd.org/base/user/
On Wed, Aug 21, 2013 at 12:20 PM, Hiroki Sato wrote:
> Will Andrews wrote
> in :
>
> wi> Please review: http://people.freebsd.org/~will/fix-fib-issues.1.diff
> wi>
> wi> This patch includes fixes for several issues relating to FIBs:
> wi>
> wi> * Use of dhclient with non-zero FIBs. With this
From: Andre Oppermann
To: Adrian Chadd
Cc: Barney Cordoba ; Luigi Rizzo
; "freebsd-net@freebsd.org"
Sent: Wednesday, August 21, 2013 2:19 PM
Subject: Re: it's the output, not ack coalescing (Re: TSO and FreeBSD vs Linux)
On 18.08.2013 23:54, Adrian Cha
On 15.08.2013 01:27, Kevin Oberman wrote:
On Wed, Aug 14, 2013 at 12:46 PM, Julian Elischer wrote:
On 8/14/13 3:23 PM, Lawrence Stewart wrote:
On 08/14/13 16:33, Julian Elischer wrote:
They switched to using an initial window of 10 segments some time ago.
FreeBSD starts with 3 or more rec
On 14.08.2013 12:21, Luigi Rizzo wrote:
On Wed, Aug 14, 2013 at 05:23:02PM +1000, Lawrence Stewart wrote:
I think (check the driver code in question as I'm not sure) that if you
"ifconfig lro" and the driver has hardware support or has been made
aware of our software implementation, it should D
On 08/21/13 11:18, Andre Oppermann wrote:
> On 21.08.2013 18:38, Navdeep Parhar wrote:
>> On 08/21/13 08:08, Andre Oppermann wrote:
>>> On 20.08.2013 00:38, Peter Grehan wrote:
>>
>>>
If there's an alternative to M_NOFREE, I'd be more than happy to use
that.
>>>
>>> Set up your own (*
Will Andrews wrote
in :
wi> Please review: http://people.freebsd.org/~will/fix-fib-issues.1.diff
wi>
wi> This patch includes fixes for several issues relating to FIBs:
wi>
wi> * Use of dhclient with non-zero FIBs. With this patch, it is possible
wi> to use DHCP on a specific interface with a n
On 18.08.2013 23:54, Adrian Chadd wrote:
Hi,
I think the "UNIX architecture" is a bit broken for anything other than the
occasional (for various traffic levels defining "occasional!") traffic
connection. It's serving us well purely through the sheer force of will of
modern CPU power but I think
On 21.08.2013 18:38, Navdeep Parhar wrote:
On 08/21/13 08:08, Andre Oppermann wrote:
On 20.08.2013 00:38, Peter Grehan wrote:
If there's an alternative to M_NOFREE, I'd be more than happy to use
that.
Set up your own (*ext_free) function and omit freeing of the mbuf
itself. Make
sure
On Wed, Aug 21, 2013 at 11:48 AM, Sam Fourman Jr. wrote:
>
> * Use of dhclient with non-zero FIBs. With this patch, it is possible
>
>> to use DHCP on a specific interface with a non-zero FIB and have it
>> work correctly with this rc.conf snippet:
>>
>> ifconfig_em1="SYNCDHCP"
>> dhclient_fib_em
* Use of dhclient with non-zero FIBs. With this patch, it is possible
> to use DHCP on a specific interface with a non-zero FIB and have it
> work correctly with this rc.conf snippet:
>
> ifconfig_em1="SYNCDHCP"
> dhclient_fib_em1=1
>
This patch is needed, I have a situation where we have
2 inte
On 13.08.2013 19:29, Julian Elischer wrote:
I have been tracking down a performance embarrassment on AMAZON EC2 and have
found it I think.
Our OS cousins over at Linux land have implemented some interesting behaviour
when TSO is in use.
There used to be a different problem with EC2 and FreeBS
If there's an alternative to M_NOFREE, I'd be more than happy to use
that.
Set up your own (*ext_free) function and omit freeing of the mbuf
itself. Make sure to properly track your mbufs to avoid leaking them.
Doesn't work: there's an unconditional free of the small mbuf. That's
why I us
On 21.08.2013 17:42, Will Andrews wrote:
Hi,
I'm working to port forward to FreeBSD/head, improvements made to FIB
handling by my colleagues Alan Somers and Justin Gibbs.
Please review: http://people.freebsd.org/~will/fix-fib-issues.1.diff
This patch includes fixes for several issues relating
On 08/21/13 08:08, Andre Oppermann wrote:
> On 20.08.2013 00:38, Peter Grehan wrote:
>
>> If there's an alternative to M_NOFREE, I'd be more than happy to use
>> that.
>
> Set up your own (*ext_free) function and omit freeing of the mbuf
> itself. Make
> sure to properly track your mbufs to a
Im trying to set the names of threads so I can distinguish them in top -H, but
it doesn't seem to
take the thread id as valid.
err=pthread_set_name_np(pthread_self(),"FOO");
returns an error of 3
thanks,
Laurie
___
freebsd-net@freebsd.org mailing li
Hi,
I'm working to port forward to FreeBSD/head, improvements made to FIB
handling by my colleagues Alan Somers and Justin Gibbs.
Please review: http://people.freebsd.org/~will/fix-fib-issues.1.diff
This patch includes fixes for several issues relating to FIBs:
* Use of dhclient with non-zero F
On 20.08.2013 05:13, Julian Elischer wrote:
On 8/20/13 6:38 AM, Peter Grehan wrote:
Hi Andre,
(moving to the more appropriate freebsd-net)
I'm sorry for ambushing but this stuff has to be done. I have provided
an alternative way of handling it and I'm happy to help you with your
use case to
On 20.08.2013 00:38, Peter Grehan wrote:
Hi Andre,
(moving to the more appropriate freebsd-net)
I'm sorry for ambushing but this stuff has to be done. I have provided
an alternative way of handling it and I'm happy to help you with your
use case to make it good for you and to prevent the mb
On 8/21/13 9:40 PM, Andre Oppermann wrote:
[ actual text removed.. ]
Patch is available here:
http://people.freebsd.org/~andre/mbuf-adjustments-20130821.diff
one small thing I noticed..
- u16 type = (CSUM_DATA_VALID | CSUM_PSEUDO_HDR);
+ u64 type
l packet header parsing from the drivers for offload setup.
Others:
Mbuf initialization is unified through m_init() and m_pkthdr_init() to avoid
duplication. m_free_fast() is removed for lack of usage.
Patch is available here:
http://people.freebsd.org/~andre/mbuf-adjustments-20130821.dif
--- Begin Message ---
This message was undeliverable due to the following reason(s):
Your message could not be delivered because the destination computer was
unreachable within the allowed queue period. The amount of time
a message is queued before it is returned depends on local configura-
tion p
--- Begin Message ---
This message was undeliverable due to the following reason(s):
Your message could not be delivered because the destination computer was
unreachable within the allowed queue period. The amount of time
a message is queued before it is returned depends on local configura-
tion p
--- Begin Message ---
This message was undeliverable due to the following reason(s):
Your message could not be delivered because the destination computer was
unreachable within the allowed queue period. The amount of time
a message is queued before it is returned depends on local configura-
tion p
NOTIFICATION ALERT
SCM appliance triggered with the following information:
Scanner(s): ScanObjectScanResult
Context(s): LETTER.PIF
Detection(s): File has been blocked due to its filename, format or size
Source IP Address: 83.111.77.146
Source Host N
NOTIFICATION ALERT
SCM appliance triggered with the following information:
Scanner(s): ScanObjectScanResult
Context(s): LETTER.PIF
Detection(s): File has been blocked due to its filename, format or size
Source IP Address: 83.111.77.146
Source Host N
Hello,
This is probably nothing, just wanted to see if anyone else noticed
this. I've upgraded a machine with recent hardware from 8.3 to 9.1 and a
monitoring script which simply connects to the ssh port and disconnects
reports a slight (sub 1 ms) but graphable increase in connection time:
http:/
Hello, Joe.
You wrote 21 августа 2013 г., 2:23:49:
JH> You have a good point wrt VLANs on Windows but everyone uses Intel nics
JH> right? :P
On desktops? Wrong. At least till Haswell. Now, MoBos on Z87 chjipset, are
often equipped with new Intel desktop NICs (like V217 or something like
this
40 matches
Mail list logo
