In article <21290.60558.750106.630...@hergotha.csail.mit.edu>, I wrote:
>Since we put this server into production, random network system calls
>have started failing with [EFBIG] or maybe sometimes [EIO]. I've
>observed this with a simple ping, but various daemons also log the
>errors:
>Mar 20 09:
In article <2354c099-c801-43d2-8ee9-0da0aaad8...@bangj.com>,
pusat...@bangj.com write:
>I read the draft and wasn't sure what problem they were trying to solve.
The problem of having zillions of IPv6 addresses in use on a network
with far fewer than a zillion actual end stations, which no network
I have a machine (actually six of them) with an Intel dual-10G NIC on
the motherboard. Two of them (so far) are connected to a network
using jumbo frames, with an MTU a little under 9k, so the ixgbe driver
allocates 32,000 9k clusters for its receive rings. I have noticed,
on the machine that is
< said:
> I am not strongly opposed to trying the 4k mbuf pool for all larger sizes,
> Garrett maybe if you would try that on your system and see if that helps
> you, I could envision making this a tunable at some point perhaps?
If you can provide a patch I can certainly build it in to our kernel
< said:
> [stuff I wrote deleted]
> You have an amd64 kernel running HEAD or 9.x?
Yes, these are 9.1 with some patches to reduce mutex contention on the
NFS server's replay "cache".
> Jumbo pages come directly from the kernel_map which on amd64 is 512GB.
> So KVA shouldn't be a problem. Your pr
< said:
> Yes, in the past the code was in this form, it should work fine Garrett,
> just make sure
> the 4K pool is large enough.
I take it then that the hardware works in the traditional way, and
just keeps on using buffers until the packet is completely written,
then sets a field on the ring d
<
said:
> If reducing the size to 4K doesn't fix the problem, you might want to
> consider shrinking the tunable vfs.nfsd.tcphighwater and suffering
> the increased CPU overhead (and some increased mutex contention) of
> calling nfsrv_trimcache() more frequently.
Can't do that -- the system beco
<
said:
> The cached replies are copies of the mbuf list done via m_copym().
> As such, the clusters in these replies won't be free'd (ref cnt -> 0)
> until the cache is trimmed (nfsrv_trimcache() gets called after the
> TCP layer has received an ACK for receipt of the reply from the client).
I
<
said:
> I suspect this indicates that it isn't mutex contention, since the
> threads would block waiting for the mutex for that case, I think?
No, because our mutexes are adaptive, so each thread spins for a while
before blocking. With the current implementation, all of them end up
doing this
<
said:
> around the highwater mark basically indicates this is working. If it wasn't
> throwing away replies where the receipt has been ack'd at the TCP
> level, the cache would grow very large, since they would only be
> discarded after a loonnngg timeout (12hours unless you've changes
> NFSRVC
In article <20795.29370.194678.963...@hergotha.csail.mit.edu>, I wrote:
>< said:
>> I've thought about this. My concern is that the separate thread might
>> not keep up with the trimming demand. If that occurred, the cache would
>> grow veryyy laarrggge, with effects like running out of mbuf cluste
< said:
> Yes, in the past the code was in this form, it should work fine Garrett,
> just make sure
> the 4K pool is large enough.
[Andre Oppermann's patch:]
>> if (adapter->max_frame_size <= 2048)
adapter-> rx_mbuf_sz = MCLBYTES;
>> - else if (adapter->max_frame_size <= 4096)
>> + el
In article <513db550.5010...@freebsd.org>, an...@freebsd.org writes:
>Garrett's problem is receive side specific and NFS can't do much about it.
>Unless, of course, NFS is holding on to received mbufs for a longer time.
Well, I have two problems: one is running out of mbufs (caused, we
think, by
In article
,
jfvo...@gmail.com writes:
>How large are you configuring your rings Garrett? Maybe if you tried
>reducing them?
I'm not configuring them at all. (Well, hmmm, I did limit the number
of queues to 6 (per interface, it appears, so that's 12 in all).)
There's a limit to how much experim
In article <513e3d75.7010...@freebsd.org>, an...@freebsd.org writes:
>On 11.03.2013 17:05, Garrett Wollman wrote:
>> Well, I have two problems: one is running out of mbufs (caused, we
>> think, by ixgbe requiring 9k clusters when it doesn't actually need
>> them)
<
said:
> To be honest, I'd consider seeing a lot of non-empty receive queues
> for TCP connections to the NFS server to be an indication that it is
> near/at its load limit. (Sure, if you do netstat a lot, you will occasionally
> see a non-empty queue here or there, but I would not expect to see
<
said:
> Basically, this patch:
> - allows setting of the tcp timeout via vfs.nfsd.tcpcachetimeo
> (I'd suggest you go down to a few minutes instead of 12hrs)
> - allows TCP caching to be disabled by setting vfs.nfsd.cachetcp=0
> - does the above 2 things you describe to try and avoid the live
<
said:
> I've attached a patch that has assorted changes.
So I've done some preliminary testing on a slightly modified form of
this patch, and it appears to have no major issues. However, I'm
still waiting for my user with 500 VMs to have enough free to be able
to run some real stress tests fo
<
said:
> The patch includes a lot of drc2.patch and drc3.patch, so don't try
> and apply it to a patched kernel. Hopefully it will apply cleanly to
> vanilla sources.
> Tha patch has been minimally tested.
Well, it's taken a long time, but I was finally able to get some
testing. The user whos
In article ,
Peter Wemm quotes some advice about ZFS filesystem vdev layout:
>"1. Virtual Devices Determine IOPS
>IOPS (I/O per second) are mostly a factor of the number of virtual
>devices (vdevs) in a zpool. They are not a factor of the raw number of
>disks in the zpool. This is probably the sing
I recently put a new server running 9.2 (with a local patches for NFS)
into production, and it's immediately started to fail in an odd way.
Since I pounded this server pretty heavily and never saw the error in
testing, I'm more than a little bit taken aback. We have identical
hardware in productio
In article
,
csforge...@gmail.com writes:
>50/27433/0 requests for jumbo clusters denied (4k/9k/16k)
This is going to screw you. You need to make sure that no NIC driver
ever allocates 9k jumbo pages -- unless you are using one of those
mythical drivers that can't do scatter/gather DMA on receiv
In article <201407151034.54681@freebsd.org>, j...@freebsd.org writes:
>Hmm, I am surprised by the m_pullup() behavior that it doesn't just
>notice that the first mbuf with a cluster has the desired data already
>and returns without doing anything.
The specification of m_pullup() is that it re
I'm working on (of all things) a Puppet module to configure NFS
servers, and I'm wondering if anyone expects to implement NFS over
SCTP on FreeBSD.
-GAWollman
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
In article <4c7d02bb.40...@freebsd.org> an...@freebsd.org writes:
>sendto() will not be touched or modified. It's just that on a TCP socket
>the tcp protocol will not perform an implied connect anymore. The only thing
>that changes is TCP dropping a deprecated and experimental extension and
>beh
In article <[EMAIL PROTECTED]>, Brooks
Davis writes:
>On Thu, Jun 12, 2008 at 06:30:05PM -0700, Peter Losher wrote:
>> FYI - HPN is already a build option in the openssh-portable port.
>
>I do think we should strongly consider adding the rest of it to the base.
Am I the only one who would be happ
< said:
> Garrett Wollman wrote:
>> Am I the only one who would be happier if openssh were not in the base
>> system at all?
> Quite possibly :)
> I don't think it's at all viable to ship FreeBSD without an ssh client
> in this day and age.
If that were w
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] writes:
>static int
>mpls_attach(struct socket *so)
The prototype for a protocol attach functions is
int (*pru_attach)(struct socket *so, int proto, struct thread *td);
(see sys/protosw.h). You don't have to use these arguments, but
In article <41d96b7f-f76d-4f35-ba1d-0edf810e6...@young-alumni.com>,
"Chris" writes:
>True OR False
>
>1) NDIS only works with XP drivers.
Can't answer that as I've never needed to try a Vista driver.
>2) NDIS only works with 32-bit drivers and wont work on amd64.
False, unless someone has broke
In article ,
Robert Watson writes:
>m_pullup() has to do with mbuf chain memory contiguity during packet
>processing.
Historically, m_pullup() also had one other extremely important
function: to make sure that the header data you were about to modify
was not stored in a (possibly shared) cluster
In article <4a3bf2df.6080...@freebsd.org>, Andre writes:
>2) in old T/TCP (RFC1644) which we supported in our TCP code the SYN/FIN
>combination was a valid one, though not directly intended for SYN/ACK/FIN.
It still is valid, and should be possible to generate using sendmsg()
and MSG_EOF. No
So is anyone working on an RFC 7217 ("Stable and Opaque IIDs with
SLAAC") implementation for FreeBSD yet?
-GAWollman
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd
In article
<388835013.10159778.1424820357923.javamail.r...@uoguelph.ca>,
rmack...@uoguelph.ca writes:
>I tend to think that a bias towards doing Getattr/Lookup over Read/Write
>may help performance (the old "shortest job first" principal), I'm not
>sure you'll have a big enough queue of outstandin
Here's the scenario:
1) A small number of (Linux) clients run a large number of processes
(compute jobs) that read large files sequentially out of an NFS
filesystem. Each process is reading from a different file.
2) The clients are behind a network bottleneck.
3) The Linux NFS client will issue
<
said:
> I think your other suggestions are fine, however the problem is that:
> 1) they seem complex for an edge case
> 2) turning them on may tank performance for no good reason if the
> heuristic is met but we're not in the bad situation
I'm OK with trading off performance for one user agai
<
said:
> There have been email list threads discussing how allocating 9K jumbo
> mbufs will fragment the KVM (kernel virtual memory) used for mbuf
> cluster allocation and cause grief.
The problem is not KVA fragmentation -- the clusters come from a
separate map which should prevent that -- it'
< said:
> - as you said, like ~ 64k), and allocate that way. That way there's no
> fragmentation to worry about - everything's just using a custom slab
> allocator for these large allocation sizes.
> It's kind of tempting to suggest freebsd support such a thing, as I
> can see increasing requirem
< said:
> I'm not really (or really not) comfortable with hacking and recompiling
> stuff. I'd rather not change anything in the kernel. So would it help in
> my case to lower my MTU from 9000 to 4000? If I understand correctly,
> this would need to allocate chunks of 4k, which is far more logi
< said:
> Brooks Davis wrote:
>> I'm considering adding an ifconfig -v option that would imply -m and add
>> more details like index, epoch, dname, dunit, etc.
> That would be great!
A particularly relevant feature would give `ifconfig' an option to
emit the current configuration of the interfac
< said:
> Yes, something in that direction, plus: protocols:
> IPv4, IPv6, TCP, UDP, ICMP, IPX, etc.
> Just about everything as modules.
It is not generally regarded as a good idea to make artificial
boundaries between (e.g.) IP and TCP.
-GAWollman
__
< said:
> I'm sitting here looking at that man pages for aio_read and aio_write,
> and the question occurs to me: ``Home come there is no such thing as
> an aio_connect function?''
Mostly because there is no need, since connect() doesn't transfer any
data; it just establishes a connection. If t
< said:
> That's it for now... just aio_connect() and aio_accept(). If I think of
> something else, I'll let you know.
[lots of Big Picture(R) stuff elided]
This is certainly an interesting model of program design. However,
some caution is advised. Here are the most significant issues:
- Fre
< said:
> I think that it would have to be slightly more complex than that for it to
> be secure. Instead of using syncookie/RFC1948-like generation,
> [...]
HIP! HIP! HIP!!!
-GAWollman
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/m
< said:
> I'm not so happy with a FreeBSD-only "proprietary" thing. Is there any
> proposed RFC work that provides the qualities you want? The advantage
> with T/TCP is that there was a published standard.
T/TCP was a published *non*standard, loudly blazoned "EXPERIMENTAL".
I don't see how Andr
< said:
> Signal numbers are typically represented as ints. Is there anything in
> the kernel that prevents me from, say, calling kill(2) with a second
> argument of, say, 0xdeadbeef, in other words any old random int value
> that I might care to use?
Yes. Signals are represented, in the kernel
< said:
> "Li, Qing" wrote:
>> Ran the packet tests against FreeBSD 5.3 and 6-CURRENT and both
>> respond to the SYN+FIN packets with SYN+ACK.
> This is expected behaviour because of FreeBSD used to implement T/TCP
> according to RFC1644.
Actually, it is expected behavior because FreeBSD used to
<
said:
> Right now, at least, it seems to work OK. I haven't tried witness,
> but a non-debug kernel shows a big speedup from enabling it. Do
> you think there is a chance that it could be made to work in FreeBSD?
I did this ten years ago for a previous job and was able to blow out
the stack
<
said:
> Probably the problem is largest for latency, especially in benchmarks.
> Latency benchmarks probably have to start cold, so they have no chance
> of queue lengths > 1, so there must be a context switch per packet and
> may be 2.
It has frequently been proposed that one of the deficienc
I'm commissioning a new NFS server with an Intel dual-40G XL710
interface, running 11.1. I have a few other servers with this
adapter, although not running 40G, and they work fine so long as you
disable TSO. This one ... not so much. On the receive side, it gets
about 600 Mbit/s with lots of ret
In article
r...@ixsystems.com writes:
>I have seen some work in the direction of avoiding larger than page size
>jumbo clusters in 12-CURRENT. Many existing drivers avoid the 9k cluster
>size already. The code for larger cluster sizes in iflib is #ifdef'd out
>so it maxes out at the page size j
In article <20180729011153.gd2...@funkthat.com> j...@funkthat.com
writes:
>And I know you know the problem is that over time memory is fragmented,
>so if suddenly you need more jumbo frames than you already have, you're
>SOL...
This problem instantly disappears if you preallocate several gigabyte
Does anyone have an easy patch to keep mce(4) from trying to use 9k
jumbo mbuf clusters? I think I went down this road once before but
the fix wasn't as obvious as it is for the Intel drivers. (I assume
the hardware is not so broken that it requires packets to be stored in
contiguous physical mem
<
said:
> On Fri, May 03, 2019 at 12:55:54PM -0400, Garrett Wollman wrote:
>> Does anyone have an easy patch to keep mce(4) from trying to use 9k
>> jumbo mbuf clusters? I think I went down this road once before but
>> the fix wasn't as obvious as it is for the Int
I'm a bit new to managing jails, and one of the things I'm finding I
need is a way for jails to have their own private loopback interfaces
-- so that things like sendmail and local DNS resolvers actually work
right without explicit configuration. Is there any way of making this
work short of going
The consensus when I asked seemed to be that VIMAGE+jail was the right
combination to give every container its own private loopback
interface, so I tried to build that. I noticed a few things:
1) The kernel prints out a warning message at boot time that VIMAGE is
"highly experimental". Should I
< said:
>> 2) Stopping jails with virtual network stacks generates warnings from
>> UMA about memory being leaked.
> I'm given to understand that's Known, and presumably Not Quite Trivial
> To Fix. Since I'm not starting/stopping jails repeatedly as a normal
> runtime thing, I'm ignoring it. If
I see from various searches that netmap support was added to ixl(4) --
*but* the code isn't there in 10.2. I'd like to be able to use it for
packet capture, because regular BPF on this interface (XL710) isn't
even able to keep up with 2 Gbit/s, never mind 20 Gbit/s. Can anyone
explain what happen
< said:
> i think it was committed to HEAD but never integrated in the
> stable/10.x branch. I wrote the code in jan/feb 2015.
> I think you can simply backport the driver from head.
So it turned out that this was merged -- along with an Intel driver
update that I needed anyway -- to stable/10 i
I noticed that a large number -- but by no means all -- of the packets
captured using libpcap on a netmap'ified ixl(4) interface show up as
truncated -- usually by exactly four bytes. They show up in tcpdump
like this:
18:10:05.348735 IP truncated-ip - 4 bytes missing! 128.30.xxx.xxx.443 >
yyy.y
In article
you write:
># ifconfig -m cxgbe0
>cxgbe0: flags=8943
># ifconfig cxgbe0 mtu 9000
>ifconfig: ioctl SIOCSIFMTU (set mtu): Invalid argument
I believe this device, like many others, does not allow the MTU (or
actually the MRU) to be changed once the receive ring has been set up
You may
In article you write:
>Eg, I don't see why we need another tool for some of this missing
>"ethtool" functionality; it seems like most of it would naturally fit
>into ifconfig.
>From the end-user perspective, I agree with Drew. Most of this stuff
should just be part of ifconfig.
>As to other fea
In article <1497408664.2220.3.ca...@me.com>, rpa...@me.com writes:
>I don't see any reason why we shouldn't have privacy addresses enabled
>by default. In fact, back in 2008 no one voiced their concerns.
Back in 2008 most people hadn't had their networks fall over as a
result of MLD listener rep
< said:
> Pretty sure these problems have been addressed by now, given the amount
> of computers, smart phones, tablets, etc. running with privacy
> extensions enabled.
They've been "fixed" mostly by hiding big networks behind NATs and
leaving them IPv4-only. And in some enterprises by implement
< said:
> Actually, in truth I think you can get the code right like so:
> long x = _mmm->m_ext.ref_cnt->refcnt;
> while (!atomic_cmpset_long(&_mmm->m_ext.ref_cnt->refcnt, x - 1, x))
> ;
Cool! You've just (almost) reinvented non-blocking parallel
reference-counts. Of course, what you re
< said:
> Gee, this looks suspiciously like jhb's refcount patch:
...Except that I made provision for architectures which have LL/SC
rather than CAS, which saves a few instructions.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the me
< said:
> Yes, ifconfig mtu 1500 is what you want.
Actually, no, it's not what you want (although the underlying code is
broken enough to let it ``work'' anyway). What you want is to fix the
parent network interface driver to indicate its readiness to receive
1522-octet frames by setting its i
< said:
> box a multihomed host, not a VLAN forwarder/router. The latter
> would require a mechnism to bridge/forward/filter packets between
> independant 802.1q encapsulated interfaces.
We have that. They are just interfaces -- the kernel doesn't treat
them at all differently. (I can't speak
< said:
> - It doesn't modify if_vlan.c anymore. Instead, it uses ifi_hdrlen to tell
> if_vlan.c that it supports long frames.
This looks good -- but I'm a bit confused by this segment of code:
+ #if NVLAN > 0
+ ifp->if_data.ifi_hdrlen = sizeof(struct ether_vlan_header);
+ #else
+ i
< said:
> Why are PTR records placed in zone db files separate from all other resource
> records?
Because they are in a different zone!
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
utgoing
> socket.
I think this is the wrong way around. There is enough information in
the PCB dump for identd to determine whether the socket was active- or
passive-open; identd should do the work itself.
-GAWollman
--
Garrett A. Wollman | O Siem / We are all family / O Siem / We're a
< said:
> Symptoms are -- if you change the address to an interface,
> packets to destinations to which you have talked to in the past
> will still go out with the previous address unless
> you delete and reinstall a route for that destination.
Yes. The address deletion code is supposed to mak
< said:
> Does this look reasonable to people? Based on
> http://www.FreeBSD.org/cgi/query-pr.cgi?pr=24125
> +.It Bq Er EAGAIN
> +A resource was temporarily unavailable.
> +This could indicate there are no port numbers available for use when a port
> +number is being chosen automatically.
If t
< said:
>> +Increasing the
>> +.Va net.inet.ip.portrange.last
> +sysctl variable
>> +(which defaults to 5000) may help this problem.
We really should define a special markup for these so that it is not
necessary to so frequently repeat this.
POSIX uses {braces} for potentially-configurable sy
< said:
> the ``.Brq Va sysctl.variable'' should be used. Why introduce .Sc?
For the same reason as we have .Er in addition to .Dv.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
< said:
> +.It Bq Er EAGAIN
> +A resource was temporarily unavailable when connecting a socket in
> +non-blocking mode.
> +This could indicate there are no port numbers available for use when a port
> +number is being chosen automatically.
> +Increasing the
> +.Va net.inet.ip.portrange.last
> +.X
< said:
> If the code implements what? Returning EAGAIN when no ephemeral ports are
> available? That is all the above really says, and then provides a hint
> as to how to fix it. The description is a little simplistic, as it misses
> the lowfirst-lowlast and highfirst-highlast ranges.
If no
< said:
> I know that UNIX is not allowed floating point calculation
> in the kernel, so RTT estimator is implemented as using int.
> However, I don't know the method of calculation of the now RTT, RTO
> using t_srtt, t_rttvar in kernel tcpcb and so on.
See the function tcp_xmit_timer() in netin
her the interface queue will actually
accept a packet until you try to enqueue it.
-GAWollman
--
Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same
[EMAIL PROTECTED] | O Siem / The fires of freedom
Opinions not those of| Dance in the burning flame
ewhere that TCP should ack no
fewer than 1/2 of all received data segments.
-GAWollman
--
Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same
[EMAIL PROTECTED] | O Siem / The fires of freedom
Opinions not those of| Dance in the burning flame
MIT, LCS, CRS, or NSA|
< said:
> Does this program mean that ?
>RTT = (tp)->t_srtt >> (TCP_RTT_SHIFT - TCP_DELTA_SHIFT) [ms]
>RTO = tp->t_rxtcur [ms]
No. Please take a look at W. Richard Stevens' _TCP/IP Illustrated_
series, particularly volume 2.
Nothing inside the kernel is measured in milliseconds. TCP
< said:
> By the way, my running machine is P-III 1GHz with i820 chip and
> FreeBSD-4.0-RELEASE.
> Is the length of time tick for this plathome invert of 1GHz?
> (1/10^-9 [s])? or 10 [ms] (I think it is the time ticks for
> FreeBSD)?
The system timer ticks at a rate of 100 Hz on all IA32 process
< said:
> The error message is kind of misleading, i wonder if we can
> replace the return value in sys/net/rtsock.c with
> ENOMSG /* No message of desired type */ ?
I think at one point it was returning ENOENT. There are no good error
messages for this purpose; programs should do a better job
< said:
> could you test this patch and compare the results.
> By generating an ACK for every segment with the TH_PSH flag set
> I found a significant increase in throughput.
I don't think this is right.
I think what we want to do is:
if (callout_pending(tp->tt_delack)) {
ely where previously we would just
delay an already-schedule delayed ack.
-GAWollman
--
Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same
[EMAIL PROTECTED] | O Siem / The fires of freedom
Opinions not those of| Dance in the burning flame
MIT, LCS, CRS, or NSA|
< said:
> Whatever happened to TF_DELACK anyway?
It was removed since it is no longer necessary. The same information
can be gleaned from callout_pending(tp->tt_delack).
> SW5kZXg6IHRjcF9pbnB1dC5jDQo9PT09PT09PT09PT09PT09PT09PT09PT09
> PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQp
< said:
> I apologize for not getting this.. I'll try another question: why
> doesn't "arp -d x.y.z.w" just delete whatever ARP entry there is
> for x.y.z.w no matter what kind it is?
Because it doesn't know what kind is there. It could find out, but
then you'd have a race condition, and in any
to flush.
-GAWollman
--
Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same
[EMAIL PROTECTED] | O Siem / The fires of freedom
Opinions not those of| Dance in the burning flame
MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick
To Unsub
<
said:
> server. If you think specifying multiple recursive servers in
> /etc/resolv.conf will save a heavily loaded host, like a mail box, you
> will be in for one hellofa surprise when your primary resolver goes down!
A ``heavily loaded host'' should only have one nameserver en
< said:
> For this reason turning off TCP_CORK pushes out queued data, but
> this isn't the case for TCP_NOPUSH.
This is a long-standing bug. You are welcome to fix it.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
<
said:
> Then shortly thereafter, with the sockbuf only slightly drained, new
> write events will come up in whatever polling method you're using,
> and you get to fire off another 1000 syscalls just to add an
> extremely small amount of data.
SO_SNDLOWAT
-GAWollman
To Unsubscribe: send ma
< said:
> Wouldn't the socket low water mark address this though as long
> as it was > size of the http header?
No. TCP is (supposed to be) oblivious to the send low-water mark.
The only code that looks at it is the code which determines whether a
process blocked or selecting on the socket shou
< said:
> Has anyone else encountered showmount returning connections that do not
> exist?
Since NFS is usually connectionless, the best `showmount' can do is to
tell you which clients have *ever* received the root file handle for
the given filesystem. (Until such time as that file system is
re
< said:
> ENOBUFS == ESYSADMINNEEDSTORAISENMBCLUSTERS
BT! Wrong, but thanks for playing.
ENOBUFS is returned in many more circumstances than simply ``out of
mbufs''.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
< said:
> A starting point, increment, and ceiling
NMBCLUSTERS *is* the ceiling. No memory is actually allocated
(although virtual address space is) until those clusters are actually
requested.
> based on the memory size of the system
That would be an improvement, but recall that many of thes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
< said:
> Can anyone comment on this patch?
> http://www.kame.net/dev/cvsweb.cgi/kame/freebsd4/sys/kern/uipc_socket.c
I don't necessarily agree that the previous behavior was wrong, but
I'm willing to bet that a lot of programs don't bother to chec
< said:
> on a similar subject (UDP sockets), i notice that
> socket buffers do not have a pointer to the end of
> the queued mbufs, so sbappend*() routines have to scan the
> list of queued bufs. As you can imagine this is
> causing some nasty effect when a receiver is slow.
I've thought about
y Jeff Mogul (then at DEC
in Palo Alto) about five years ago; I have a physical copy of the
paper buried somewhere in my office.
-GAWollman
--
Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same
[EMAIL PROTECTED] | O Siem / The fires of freedom
Opinions not those
< said:
> This is similar to the way most VxWorks network drivers operate:
Right -- in fact, as I recall, Mogul's paper mentions that his
solution is very similar to the way many RTOSes operate.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the
< said:
> A) So, do we bump the sockets to use 'int' for so->so_qlimit?
Make it be `u_short'. (Actually, I'm not sure why all three of those
members aren't unsigned. It would make more sense that way.)
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net"
< said:
> ISTR at one time you would instead get the actual sockaddr of the
> just-closed socket, rather than a bogus sockaddr... and that is the
> behavior one would expect.
As itojun pointed out, accept() used to just block if the socket it
thought it was going to give you turned out not to be
1 - 100 of 249 matches
Mail list logo
