Joshua Goodall wrote:
> On Sat, May 18, 2002 at 05:48:19PM -0700, Terry Lambert wrote:
> > Joshua Goodall wrote:
> > > On Sat, May 18, 2002 at 03:28:34PM -0700, Terry Lambert wrote:
> > > > No. TCP. RPC over UDP is really a silly idea. If you need
> > > > reliable delivery, then don't use a pro
On Sat, May 18, 2002 at 13:15:43 -0400, Don Bowman wrote:
> > Andrew Gallatin writes:
> >> Kenneth D. Merry writes:
> >> >
> >> > I have released a new set of zero copy sockets patches, against
> -current
> >> > from today (May 17th, 2002).
> >
> > Hi Ken,
> >
> > I'm glad to see that you're
On Sat, May 18, 2002 at 13:12:09 -0400, Andrew Gallatin wrote:
>
> Kenneth D. Merry writes:
> >
> > I have released a new set of zero copy sockets patches, against -current
> > from today (May 17th, 2002).
> >
> > The main change is to deal with the vfs_ioopt changes that Alan Cox made in
On Sat, May 18, 2002 at 09:03:38 -0400, John Baldwin wrote:
>
> On 18-May-2002 Kenneth D. Merry wrote:
> > On Fri, May 17, 2002 at 23:02:55 -0700, Alfred Perlstein wrote:
> >> * Kenneth D. Merry <[EMAIL PROTECTED]> [020517 22:40] wrote:
> >> >
> >> > I have released a new set of zero copy socket
On Sat, May 18, 2002 at 05:48:19PM -0700, Terry Lambert wrote:
> Joshua Goodall wrote:
> > On Sat, May 18, 2002 at 03:28:34PM -0700, Terry Lambert wrote:
> > > No. TCP. RPC over UDP is really a silly idea. If you need
> > > reliable delivery, then don't use a protocol with "unreliable"
> > > as
Joshua Goodall wrote:
> On Sat, May 18, 2002 at 03:28:34PM -0700, Terry Lambert wrote:
> > No. TCP. RPC over UDP is really a silly idea. If you need
> > reliable delivery, then don't use a protocol with "unreliable"
> > as the first word of it's name. 8-).
>
> UDP may well be perfectly viable
On Sat, May 18, 2002 at 03:28:34PM -0700, Terry Lambert wrote:
> No. TCP. RPC over UDP is really a silly idea. If you need
> reliable delivery, then don't use a protocol with "unreliable"
> as the first word of it's name. 8-).
UDP may well be perfectly viable as a RPC transport, but Terry's
m
John Baldwin wrote:
> > This is actually what I was saying was bad: a static function
> > per mutex declaration.
>
> Umm, no, there is _one_ global function that we call. Why not check
> the actual code?
Are you talking about a P4 branch, and not the main repository?
> Why don't you read the c
Terry Lambert wrote:
> The really cool thing is that this means I can shout on the wire at
> the right time, cause a collision, and effectively stace an undetectable
> denial of service attack against your servers, by making it drop large
> UDP datagrams IP frags.
This "attack" works against any
Terry Lambert wrote:
> No. TCP. RPC over UDP is really a silly idea. If you need
> reliable delivery, then don't use a protocol with "unreliable"
> as the first word of it's name. 8-).
The U in UDP is for "User". See RFC768.
NFS over UDP works just fine in the majority of cases, and for slow
On 18-May-2002 Terry Lambert wrote:
> John Baldwin wrote:
>> On 18-May-2002 Terry Lambert wrote:
>> > John Baldwin wrote:
>> >> > God, it's annoying that a statically declared mutex is not
>> >> > defacto initialized.
>> >>
>> >> Is it in solaris?
>> >
>> > It isn't in FreeBSD because of the need
John Baldwin wrote:
> On 18-May-2002 Terry Lambert wrote:
> > John Baldwin wrote:
> >> > God, it's annoying that a statically declared mutex is not
> >> > defacto initialized.
> >>
> >> Is it in solaris?
> >
> > It isn't in FreeBSD because of the need to link mutex'es into
> > the "witness protect
Don Bowman wrote:
> > Andrew Gallatin writes:
> >> Kenneth D. Merry writes:
> >> >
> >> > I have released a new set of zero copy sockets patches, against
> -current
> >> > from today (May 17th, 2002).
> >
> > Hi Ken,
> >
> > I'm glad to see that you're still maintining this!
> >
> > Assuming th
On 18-May-2002 Terry Lambert wrote:
> John Baldwin wrote:
>> > God, it's annoying that a statically declared mutex is not
>> > defacto initialized.
>>
>> Is it in solaris?
>
> It isn't in FreeBSD because of the need to link mutex'es into
> the "witness protection program". 8-).
Actually, ther
John Baldwin wrote:
> > God, it's annoying that a statically declared mutex is not
> > defacto initialized.
>
> Is it in solaris?
It isn't in FreeBSD because of the need to link mutex'es into
the "witness protection program". 8-).
> > Yeah, I understand the "witness" crap (if it's there); tha
Does anyone know if kernel profiling is working in FreeBSD 5.0DP?
Andrew Tate
mailto:[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Attila Nagy wrote:
> > If the card on the receiving could not receive so many back to back
> > packets and looses one or more, nfs will get stuck retrying the same big
> > packet and the same thing happening over and over.
>
> Yep, but that's not my case. If this would be the problem, I guess
> c
Attila Nagy wrote:
> > Sending datagrams bigger than the MTU is a bad idea.
>
> It depends on what do you want to do with that NFS server :)
Sure. Maybe you want to use up it's mbufs by jamming the frag
reassembly queue for IP full of N-1 frags using 64K USP packets.
> I want to get out from
Andrew Reilly wrote:
> On Sat, 2002-05-18 at 18:53, Terry Lambert wrote:
> > Sending datagrams bigger than the MTU is a bad idea.
> >
> > I would be real tempted to drop the packets and send "don't fragment"
> > ICMP responses to beat up anyone who abused UDP by sending larger
> > than the MTU.
>
> Andrew Gallatin writes:
>> Kenneth D. Merry writes:
>> >
>> > I have released a new set of zero copy sockets patches, against
-current
>> > from today (May 17th, 2002).
>
> Hi Ken,
>
> I'm glad to see that you're still maintining this!
>
> Assuming the mutex issues get sorted out, what d
Kenneth D. Merry writes:
>
> I have released a new set of zero copy sockets patches, against -current
> from today (May 17th, 2002).
>
> The main change is to deal with the vfs_ioopt changes that Alan Cox made in
> kern_subr.c. (They conflicted a bit with the zero copy receive code.)
>
Greetings all,
I'm currently STFWing for info on proper VRRP implementation on
FreeBSD.
My motivations are those mentioned by Terry in a -net thread last
July... Win2000 Advanced Server clustering is rather cool. I'd
like FreeBSD to similarly support multiple MAC addresses (and
emulate via mul
:Alfred Perlstein wrote:
:> * Kenneth D. Merry <[EMAIL PROTECTED]> [020517 23:31] wrote:
:> > The problem here is that the mutex needs to be initialized before I can
:> > acquire it, and there's going to be a race between checking to see
:> > whether it has been initialized and actually initializi
On 18-May-2002 Terry Lambert wrote:
> Alfred Perlstein wrote:
>> * Kenneth D. Merry <[EMAIL PROTECTED]> [020517 23:31] wrote:
>> > The problem here is that the mutex needs to be initialized before I can
>> > acquire it, and there's going to be a race between checking to see
>> > whether it has be
On 18-May-2002 Kenneth D. Merry wrote:
> On Fri, May 17, 2002 at 23:02:55 -0700, Alfred Perlstein wrote:
>> * Kenneth D. Merry <[EMAIL PROTECTED]> [020517 22:40] wrote:
>> >
>> > I have released a new set of zero copy sockets patches, against -current
>> > from today (May 17th, 2002).
>> >
>> >
hi -net,
recently i acquired a pair of above cards, one of which i use with w2k
and the other with freebsd's fxp(4). with w2k i am able to set various
options using intel's proset utility (cpu usage vs. throughput, pci bus
efficiency etc.). my question is: are these settings stored into the
s
Hello,
> If the card on the receiving could not receive so many back to back
> packets and looses one or more, nfs will get stuck retrying the same big
> packet and the same thing happening over and over.
Yep, but that's not my case. If this would be the problem, I guess
changing from gx to em wo
Hello,
> Sending datagrams bigger than the MTU is a bad idea.
It depends on what do you want to do with that NFS server :)
I want to get out from that several hundred megabits per second, so I
can't use <1500 bytes MTU.
Just for comparison:
when using <1500 bytes MTU (as close as possible to the
On Sat, 2002-05-18 at 18:53, Terry Lambert wrote:
>
> Sending datagrams bigger than the MTU is a bad idea.
>
> I would be real tempted to drop the packets and send "don't fragment"
> ICMP responses to beat up anyone who abused UDP by sending larger
> than the MTU.
>
> I guess this is about Linu
> Attila Nagy wrote:
> > > > the "em" driver (if "gx" is already in the initial plan), because it
> > > > reportedly works better (for example I couldn't do NFS serving with UDP
> > > > packets bigger than the MTU with that, while the "em" driver works OK).
> > >
> > > It *does* frag packets bigge
Alfred Perlstein wrote:
> * Kenneth D. Merry <[EMAIL PROTECTED]> [020517 23:31] wrote:
> > The problem here is that the mutex needs to be initialized before I can
> > acquire it, and there's going to be a race between checking to see
> > whether it has been initialized and actually initializing it
* Kenneth D. Merry <[EMAIL PROTECTED]> [020517 23:31] wrote:
>
> The problem here is that the mutex needs to be initialized before I can
> acquire it, and there's going to be a race between checking to see
> whether it has been initialized and actually initializing it.
>
...
> Suggestions?
*sla
Attila Nagy wrote:
> > > the "em" driver (if "gx" is already in the initial plan), because it
> > > reportedly works better (for example I couldn't do NFS serving with UDP
> > > packets bigger than the MTU with that, while the "em" driver works OK).
> >
> > It *does* frag packets bigger than the M
Hello,
> > the "em" driver (if "gx" is already in the initial plan), because it
> > reportedly works better (for example I couldn't do NFS serving with UDP
> > packets bigger than the MTU with that, while the "em" driver works OK).
> It *does* frag packets bigger than the MTU, right?
netstat didn
34 matches
Mail list logo
