On Wed, Mar 14, 2007 at 06:45:20PM -0700, Kip Macy wrote:
> Apologies in advance if you have already answered this question
> elsewhere - can you point me to a HOWTO for replicating the test in my
> local environment?
Well it's not completely spelled out...but most of the steps are
documented in h
Apologies in advance if you have already answered this question
elsewhere - can you point me to a HOWTO for replicating the test in my
local environment?
-Kip
On 3/14/07, Kris Kennaway <[EMAIL PROTECTED]> wrote:
I have recently started looking at database performance over gigabit
ethernet,
I have recently started looking at database performance over gigabit
ethernet, and there seems to be a bottleneck coming from the way route
reference counting is implemented. On an 8-core system it looks like
we spend a lot of time waiting for the rtentry mutex:
maxtotal wait_total
OK, I have used these ken mods for my file server/nat/router/firewall servers
for years. (kern ops then question)
#Mt e
options IPFIREWALL
options IPDIVERT
options IPFIREWALL_VERBOSE
options IPSTEALTH
options FAST_IPSEC
#smbfs stuff
options NETSMB
options NETSMBCRYPTO
options LIBMCHAIN
option
Wednesday, March 14, 2007, 7:00:13 PM, Bruce M. Simpson wrote:
BMS> Gleb Smirnoff wrote:
>> AFAIK, the problem needs a more generic approach. I see two approaches.
>>
>> 1) Introduce RTM_CHANGEADD, a command that will forcibly add route,
>> deleting all conflicting ones. Use this command in in_add
Gleb Smirnoff wrote:
I was afraid that this would raise an argument on multipath routing. Let's
temporary do not speak about multipath but just decide what is the correct
way to remove conflicting routes when we are assigning an IP prefix to a
local interface?
My suggestion is to take the seco
On Wed, Mar 14, 2007 at 04:00:13PM +, Bruce M. Simpson wrote:
B> The proposed changes also constitute a hack.
B>
B> I understand that they are being proposed to address problems we
B> currently have in the stack, i.e. that we do not support multipathing,
B> though it is more than likely they
Gleb Smirnoff wrote:
AFAIK, the problem needs a more generic approach. I see two approaches.
1) Introduce RTM_CHANGEADD, a command that will forcibly add route,
deleting all conflicting ones. Use this command in in_addprefix().
2) In rt_flags field we still have several extra bits. We can use
t
Hi Tatuya,
Well after getting distracted for a while, I am back with this one.
On Fri, Jan 26, 2007 at 03:13:07AM +0900, JINMEI Tatuya / [EMAIL
PROTECTED]@C#:H wrote:
> > On Sun, 21 Jan 2007 09:32:44 +0200,
> > John Hay <[EMAIL PROTECTED]> said:
>
> >> There's another workaround for pe
On Wed, Mar 14, 2007 at 01:20:23PM +0300, Yar Tikhiy wrote:
> Hi folks,
>
> Quite a while ago I noticed that our ioctl handlers get the ioctl
> command via u_long, but ether_ioctl()'s command argument is int.
> This disarray dates back to 1998, when ioctl functions started to
> take u_long as the
On Wed, Mar 14, 2007 at 05:11:43PM +0300, Yar Tikhiy wrote:
> On Wed, Mar 14, 2007 at 04:35:06AM -0700, Luigi Rizzo wrote:
...
> > actually, i think it is the kernel itself (in the setsockopt handler,
> > once it validates the rule) that should load the module, and not leave
> > the task to the use
On Wed, Mar 14, 2007 at 04:35:06AM -0700, Luigi Rizzo wrote:
> On Wed, Mar 14, 2007 at 12:57:26PM +0300, Yar Tikhiy wrote:
> > On Tue, Mar 13, 2007 at 12:45:43AM -0700, Luigi Rizzo wrote:
> ...
> > > Making the load on demand would require a bit of additional code because
> > > it depends on the ac
Bruce,
many thanks for your fast response.
Bruce M. Simpson <[EMAIL PROTECTED]> wrote on 14 Mar 2007 13:09:
> The conditional in the second patch is a no-op as the open will be
> forbidden if the user did not have privilege to open the tap. Bringing
No. A process running with root rights can al
Aniruddha Bohra wrote:
Hi,
The ifnet manpage contains entries for the following routines which do
not exist in the ifnet struct.
committed, thanks!
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsu
Hi,
Frank Behrens wrote:
If we have no possibility to mark the interface as UP for the non-root process the
net.link.tap.user_open=1 is useless, because we can not transmit any packets. With the
patch the interface goes UP only, when the administrator allowed non-root user access.
The co
On Wed, 14 Mar 2007, Keith Arner wrote:
On 3/11/07, Robert Watson <[EMAIL PROTECTED]> wrote:
Yes -- right now the in-bound TCP path is essentially serialized because of
the tcbinfo lock. The reason for this is that the tcbinfo lock doesn't
just protect the inpcb chains during lookup, but a
Yar Tikhiy wrote:
Hi folks,
Quite a while ago I noticed that our ioctl handlers get the ioctl
command via u_long, but ether_ioctl()'s command argument is int.
This disarray dates back to 1998, when ioctl functions started to
take u_long as the command, but ether_ioctl() was never fixed.
Fortunat
On 3/11/07, Robert Watson <[EMAIL PROTECTED]> wrote:
Yes -- right now the in-bound TCP path is essentially serialized because
of
the tcbinfo lock. The reason for this is that the tcbinfo lock doesn't
just
protect the inpcb chains during lookup, but also effectively acts as a
reference to preve
Bruce M. Simpson <[EMAIL PROTECTED]> wrote on 9 Mar 2007 12:30:
> However, we also support the creation of tap/tun instances by
> non-super-users, so there is motivation for the change. Configuring a
> tap interface to up by a non-superuser should only be permitted if the
> interface itself was
Just for the reference, here is a backtrace that shows how EEXIST is
returned:
rtrequest1(1,e6560aec,e6560ae0,e6560aec,30,...) at rtrequest1+0x658^M
rtinit(c3e21500,1,1) at rtinit+0x193^M
in_addprefix(c3e21500,1,e6560b68,0,1,...) at in_addprefix+0xa1^M
in_ifinit(c3c4ec00,c3e21500,c3eb6e50,0) at
On Wed, Mar 14, 2007 at 12:57:26PM +0300, Yar Tikhiy wrote:
> On Tue, Mar 13, 2007 at 12:45:43AM -0700, Luigi Rizzo wrote:
...
> > Making the load on demand would require a bit of additional code because
> > it depends on the actual rules being loaded, and the rules are not
> > parsed at load time.
Synopsis: [net] [patch] ifconfig may not connect an interface to known network
Responsible-Changed-From-To: freebsd-net->glebius
Responsible-Changed-By: glebius
Responsible-Changed-When: Wed Mar 14 11:18:24 UTC 2007
Responsible-Changed-Why:
I'll work on this.
http://www.freebsd.org/cgi/query-pr.
On Tue, Mar 13, 2007 at 12:45:43AM -0700, Luigi Rizzo wrote:
> On Sat, Mar 10, 2007 at 06:35:34PM +0300, Yar Tikhiy wrote:
> > Hi folks,
> >
> > Just noticed that neither ipfw(8) nor /etc/rc.d/ipfw cares to load
> > dummynet.ko. It can result in a broken setup when one migrates
> > from a custom
Hi folks,
Quite a while ago I noticed that our ioctl handlers get the ioctl
command via u_long, but ether_ioctl()'s command argument is int.
This disarray dates back to 1998, when ioctl functions started to
take u_long as the command, but ether_ioctl() was never fixed.
Fortunately, our ioctl comma
24 matches
Mail list logo
