January 2002 - Darwin-kernel

NFS limited to 4K reads/writes
by Andrew Gallatin 31 Jan '02

31 Jan '02

I was playing around with NFS. Darwin seems to perform well as a server, but its performance leaves a lot to be desired as a client because it appears to crippled by a 4k read and write size limit. (verified w/tcpdump). I can reduce the size with mount_nfs, but I cannot increase it over 4K By poor performnace, I mean that Darwin reads at 12MB/sec over a 2Gb/sec link. Tru64 and FreeBSD can both read at 50MB/sec. (this is from a file warm in the server's cache; no disk I/O). Darwin performs just as well as the competition when its the server... Any chance of this 4K limit being lifted? Drew

1 0

Re: output packet queueing?
by Andrew Gallatin 30 Jan '02

30 Jan '02

Justin C. Walker writes: > > The ENOBUFS error crops up when there is no available buffer for some > required use (e.g., failing on the allocation of an mbuf to hold the > packet header). This is done in udp_output(), and un ip_output(). Yeah, I'm an idiot. I'd gotten suspicious of dlil just because its new to me. I had ifq_maxlen set too small & ip_output was dropping things. I'm pretty sure this is what was causing my real problem. Oops.. > Is this driver "virtual", or does it deal with hardware? "yes" ;-) It uses I/O Kit for hardware access only, and is otherwise a pretty much straightforward port of an existing FreeBSD / Tru64 driver with changes for Apple's dlil layer. Thanks for the help.. Drew

1 0

struct ifmedia
by Brian Wotring 30 Jan '02

30 Jan '02

Given an ifnet structure for a network interface, is it possible to determine if that interface is associated with a wireless card? The only 802.11 references I could find were in net/if_media.h, in the structure ifmedia: struct ifmedia { int ifm_mask; /* mask of changes we don't care about */ int ifm_media; /* current user-set media word */ struct ifmedia_entry *ifm_cur; /* currently selected media */ LIST_HEAD(, ifmedia_entry) ifm_list; /* list of all supported media */ ifm_change_cb_t ifm_change; /* media change driver callback */ ifm_stat_cb_t ifm_status; /* media status driver callback */ }; ... /* * IEEE 802.11 Wireless */ #define IFM_IEEE80211 0x00000080 #define IFM_IEEE80211_FH1 3 /* Frequency Hopping 1Mbps */ #define IFM_IEEE80211_FH2 4 /* Frequency Hopping 2Mbps */ #define IFM_IEEE80211_DS2 5 /* Direct Sequence 2Mbps */ #define IFM_IEEE80211_DS5 6 /* Direct Sequence 5Mbps*/ #define IFM_IEEE80211_DS11 7 /* Direct Sequence 11Mbps*/ #define IFM_IEEE80211_DS1 8 /* Direct Sequence 1Mbps */ #define IFM_IEEE80211_ADHOC 0x00000100 /* Operate in Adhoc mode */ -- Brian Wotring ( brian(a)shmoo.com ) PGP KeyID: 0x9674763D

1 0

Re: output packet queueing?
by Justin C. Walker 30 Jan '02

30 Jan '02

On Tuesday, January 29, 2002, at 08:26 AM, Andrew Gallatin wrote: Where do network drops typically happen in darwin? Eg, I'm seeing packets get dropped somewhere between udp_output() and my driver. (comparing counters in my driver and in udp_output()). The culprit is returning ENOBUFS. My driver has control of its own if_output (eg, its not going through IOKit). Packets get dropped in "the usual places": all along the path from udp_output to the inside of the driver. The ENOBUFS error crops up when there is no available buffer for some required use (e.g., failing on the allocation of an mbuf to hold the packet header). This is done in udp_output(), and un ip_output(). Is this driver "virtual", or does it deal with hardware? Since the BSD per-interface ifp->if_snd output queuing seems to be gone (or replaced somehow), I'm not sure where output queuing is happening. In Darwin, there is no enforced system queueing; the driver itself chooses the method of queueing, if any. Regards, Justin -- /~\ The ASCII Justin C. Walker, Curmudgeon-at-Large \ / Ribbon Campaign X Against HTML / \ Email

1 0

Re: tcp/udp hardware checksum offload support..
by Andrew Gallatin 29 Jan '02

29 Jan '02

Josh Graessley writes: > CSUM_TCP_SUM16 is only for the GMAC hardware, you shouldn't need to set it > for your hardware. It only causes some weird special case code to be > executed. Ideally, you should be able to get things working with the other > flags. The hardware checksum support in the kernel is still new, so it may > contain some rough edges you'll get snagged on, as you're noticing. Some of > this is addressed on a branch we're working on. > I don't recall what the psuedo header does. Perhaps someone else can help Do you mean the CSUM_PSEUDO_HDR flag? It means the device has checksummed the entire packet (including the psuedo header) and has left the csum in csum_data. > out there. I do know that you can't perform hardware udp/tcp checksums on > fragmented packets unless you're going to handle reassembly in your > hardware. The UDP or TCP checksum is in the first fragment that contains the > UDP or TCP header. All other fragments of the packet contain the IP header > followed by UDP or TCP data. You can't calculate the UDP/TCP checksum until > you've collected all fragments. I believe most stacks avoid TCP > fragmentation, so I doubt you'll see much if any of that. This will still be > a problem from UDP though. Yeah.. I don't want to collect all the fragments -- I want ip_reass() to collect them because that's its job. Eg, I want to pass the payload checksums up the stack and have ip_reass() add things up. In fact, if you look at the code, its already adding the csum's up in the "Concatenate fragments." section of ip_reass. All that needs to be done is to fix the proto layers to call in_pseudo() to adding the psuedo header sum on packets without CSUM_TCP_SUM16 or CSUM_PSEUDO_HDR set & I'll be a happy camper. FWIW, this is how it works in FreeBSD. Cheers, Drew

1 0

Re: tcp/udp hardware checksum offload support..
by Josh Graessley 29 Jan '02

29 Jan '02

On 1/29/02 8:10 AM, "Andrew Gallatin" <gallatin(a)cs.duke.edu> wrote: >>> Also, why does darwin not allow csum offloading for received ip >>> fragments using the CSUM_TCP_SUM16 method? >> >> The CSUM_TCP_SUM16 flag is used to indicate that the GMAC's checksum is >> being used. The GMAC hardware checksum has some limitations. There are a lot >> of checks for the various limitations to avoid cases where the hardware does >> the wrong thing. I believe IP fragments may be one of the cases where the >> chipset does the wrong thing. > > Hehe.. Yes, but all the world's not a GMAC. It appears that the GMAC > specific code has replaced the general code. Eg, if you set > CSUM_DATA_VALID without setting CSUM_TCP_SUM16, you're ignored. The > only to not be ignored is to set either CSUM_PSEUDO_HDR or > CSUM_TCP_SUM16. Setting CSUM_PSEUDO_HDR gives me the same problem -- > no frags can be dealt with unless I want to implement reassembly in my > driver (I don't). So I'm screwed either way. CSUM_TCP_SUM16 is only for the GMAC hardware, you shouldn't need to set it for your hardware. It only causes some weird special case code to be executed. Ideally, you should be able to get things working with the other flags. The hardware checksum support in the kernel is still new, so it may contain some rough edges you'll get snagged on, as you're noticing. Some of this is addressed on a branch we're working on. I don't recall what the psuedo header does. Perhaps someone else can help out there. I do know that you can't perform hardware udp/tcp checksums on fragmented packets unless you're going to handle reassembly in your hardware. The UDP or TCP checksum is in the first fragment that contains the UDP or TCP header. All other fragments of the packet contain the IP header followed by UDP or TCP data. You can't calculate the UDP/TCP checksum until you've collected all fragments. I believe most stacks avoid TCP fragmentation, so I doubt you'll see much if any of that. This will still be a problem from UDP though. > There should be a 3rd case. Eg: > > --- tcp_input.c Sun Dec 16 10:59:16 2001 > +++ tcp_input.c.new Tue Jan 29 11:06:45 2002 > @@ -520,7 +520,10 @@ > else { > if (m->m_pkthdr.csum_flags & CSUM_PSEUDO_HDR) > th->th_sum = m->m_pkthdr.csum_data; > - else goto dotcpcksum; > + else > + th->th_sum = in_pseudo(ip->ip_src.s_addr, > + ip->ip_dst.s_addr, htonl(m->m_pkthdr.csum_data + > + ip->ip_len + IPPROTO_TCP)); > } > th->th_sum ^= 0xffff; I believe you're right. In fact, something very similar to this is done in FreeBSD 4.4. We have these changes on a branch that we're hoping to get in to xnu some time soon. If you'd like to be able to track the progress, you're welcome to file a bug. -josh

1 0

output packet queueing?
by Andrew Gallatin 29 Jan '02

29 Jan '02

Where do network drops typically happen in darwin? Eg, I'm seeing packets get dropped somewhere between udp_output() and my driver. (comparing counters in my driver and in udp_output()). The culprit is returning ENOBUFS. My driver has control of its own if_output (eg, its not going through IOKit). Since the BSD per-interface ifp->if_snd output queuing seems to be gone (or replaced somehow), I'm not sure where output queuing is happening. Can somebody shed some light on this, please? Thanks, Drew

1 0

Re: tcp/udp hardware checksum offload support..
by Andrew Gallatin 29 Jan '02

29 Jan '02

Josh Graessley writes: > > To make recv. checksum offloading work with my device, I needed to set > > if_hwassist to a non-zero value which is nonsense wrt to xmit offload > > capabilities. This seems broken to me. > > I believe the check for if_hwassist was done to try and cover up any bugs. I > think it was thought that if the interface that packet was received on did > not support hardware checksums then it must have set those bits by accident. > Not very helpful. You might want to file a bug against this. Just did, thanks.. > > Also, why does darwin not allow csum offloading for received ip > > fragments using the CSUM_TCP_SUM16 method? > > The CSUM_TCP_SUM16 flag is used to indicate that the GMAC's checksum is > being used. The GMAC hardware checksum has some limitations. There are a lot > of checks for the various limitations to avoid cases where the hardware does > the wrong thing. I believe IP fragments may be one of the cases where the > chipset does the wrong thing. Hehe.. Yes, but all the world's not a GMAC. It appears that the GMAC specific code has replaced the general code. Eg, if you set CSUM_DATA_VALID without setting CSUM_TCP_SUM16, you're ignored. The only to not be ignored is to set either CSUM_PSEUDO_HDR or CSUM_TCP_SUM16. Setting CSUM_PSEUDO_HDR gives me the same problem -- no frags can be dealt with unless I want to implement reassembly in my driver (I don't). So I'm screwed either way. There should be a 3rd case. Eg: --- tcp_input.c Sun Dec 16 10:59:16 2001 +++ tcp_input.c.new Tue Jan 29 11:06:45 2002 @@ -520,7 +520,10 @@ else { if (m->m_pkthdr.csum_flags & CSUM_PSEUDO_HDR) th->th_sum = m->m_pkthdr.csum_data; - else goto dotcpcksum; + else + th->th_sum = in_pseudo(ip->ip_src.s_addr, + ip->ip_dst.s_addr, htonl(m->m_pkthdr.csum_data + + ip->ip_len + IPPROTO_TCP)); } th->th_sum ^= 0xffff; (similar for udp_input()). Drew

1 0

Re: ProjectBuilder and Filesystem kmods
by Justin C. Walker 29 Jan '02

29 Jan '02

On Monday, January 28, 2002, at 09:46 PM, Sujal Shah wrote: Hi, I'm taking a look at porting the coda client filesystem driver from FreeBSD to Darwin. There are two fundamental problems I'm running into, one sort of frivolous, the other more fundamental. I'll start with the frivolous one first. I've been trying to figure out the "proper" way to set up a ProjectBuilder project for a filesystem driver. There are several targets necessary, and scattered source. There is also very little consistency in the file system sources included with the Darwin source code. Can someone point out one of the filesystems in the darwin source as a "recommended way" to do it? You can find PB projects dealing with file systems in the Darwin repository. That should help. If not, you want to start with the "KEXT" type in PB. Now the more fundamental question: I'm just trying to understand the way that a filesystem might be implemented in darwin. In other words, what are the specific targets that are required to get it to work. Also, why are there different targets for kmods and kexts? I thought they were the same thing... KEXTs and kmods are not the same; the latter is a building block on which the former is built. Typically, file system and network extensions are kmods, but that is not cast in concrete. A KEXT is a collection of one or more kmods, plus some other goo. The darwin repository is replete with examples that should help by giving you working examples. Check the HOWTOs on the Apple Darwin site for details. So, my real question is, what are some good pointers on doing something like this. I have read most of the included documentation regarding writing KEXTs, but haven't found anything that goes into any detail at all. I realize that most of the targets in the existing projects are pretty self explanatory, but it would be nice to understand the reasoning behind some of the layout and organization. Except for IO Kit support, the documentation is sparse. Look to the repository for examples (e.g., see the folders Networking and Filesystems in http://www.opensource.apple.com/cgi-bin/registered/cvs) Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | It's not whether you win or lose... | It's whether *I* win or lose. *--------------------------------------*-------------------------------*

1 0

Re: ProjectBuilder and Filesystem kmods
by Andrei Nikonov 29 Jan '02

29 Jan '02

Hello, I would like to integrate the Project Builder or Interface Builder with my PERL script. Where can I obtain more information on that subject? Can anyone advice me how to do it? Should I begin to learn Cocoa and Carbon? Thanx, ----------> Andrei On 29 Jan 2002, Sujal Shah wrote: > Hi, > > I'm taking a look at porting the coda client filesystem driver from > FreeBSD to Darwin. There are two fundamental problems I'm running into, > one sort of frivolous, the other more fundamental. > > I'll start with the frivolous one first. I've been trying to figure > out the "proper" way to set up a ProjectBuilder project for a filesystem > driver. There are several targets necessary, and scattered source. > There is also very little consistency in the file system sources > included with the Darwin source code. Can someone point out one of the > filesystems in the darwin source as a "recommended way" to do it? > > Now the more fundamental question: I'm just trying to understand the > way that a filesystem might be implemented in darwin. In other words, > what are the specific targets that are required to get it to work. > Also, why are there different targets for kmods and kexts? I thought > they were the same thing... > > So, my real question is, what are some good pointers on doing something > like this. I have read most of the included documentation regarding > writing KEXTs, but haven't found anything that goes into any detail at > all. I realize that most of the targets in the existing projects are > pretty self explanatory, but it would be nice to understand the > reasoning behind some of the layout and organization. > > Thanks, > > Sujal > > -- > ------ Sujal Shah ---- sujal(a)sujal.net > > http://www.sujal.net/ > _______________________________________________ > darwin-kernel mailing list | darwin-kernel(a)lists.apple.com > Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel > Do not post admin requests to the list. They will be ignored. > Andrei Nikonov Gene Technology undergraduate student tel. +372 56 9 85 85 3

1 0