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).
The main change is to deal with the vfs_ioopt changes that
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't show any
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 MTU, right?
* 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?
*slaps
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 Linux UDP NFS
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
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
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
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).
The main change is
: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.
:
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
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.)
The
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 do you think the
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.
I guess
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 that
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
changing
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, there is more to it
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 the mutex issues get sorted
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 to link mutex'es into
the
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
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 other
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 code?
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
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 as a RPC
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 sockets patches,
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 still maintining this!
26 matches
Mail list logo
