January 2002 - Darwin-kernel

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

29 Jan '02

On 1/28/02 1:22 PM, "Andrew Gallatin" <gallatin(a)cs.duke.edu> wrote: > Hi, > > I've got an "ethernet" device which can do TCP/UDP checksum offload on > receive, but not transmit. > > In ip_input(), darwin discards checksums on packets from devices whose > if_hwassist is set to 0. However, in the original FreeBSD code, > if_hwassist is meant only to tell what sort of transmit offloading a > device will do. > > 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. > 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. > BTW, its rather amusing. I loose roughly 100Mb/sec when I turn on > receiver offloading (800Mb/sec -> 700Mb/sec). I know the settings are > correct, because UDP tests show a reduction in drops due to full > socket buffers when csum offloading is on. This is a dual g4-800. > I've seen platforms where csum offload doesn't make much difference, > but this is the first platform I've seen where it actually hurts! Weird. -josh

1 0

tcp/udp hardware checksum offload support..
by Andrew Gallatin 28 Jan '02

28 Jan '02

Hi, I've got an "ethernet" device which can do TCP/UDP checksum offload on receive, but not transmit. In ip_input(), darwin discards checksums on packets from devices whose if_hwassist is set to 0. However, in the original FreeBSD code, if_hwassist is meant only to tell what sort of transmit offloading a device will do. 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. Also, why does darwin not allow csum offloading for received ip fragments using the CSUM_TCP_SUM16 method? BTW, its rather amusing. I loose roughly 100Mb/sec when I turn on receiver offloading (800Mb/sec -> 700Mb/sec). I know the settings are correct, because UDP tests show a reduction in drops due to full socket buffers when csum offloading is on. This is a dual g4-800. I've seen platforms where csum offload doesn't make much difference, but this is the first platform I've seen where it actually hurts! Thanks, Drew

1 0

Re: detecting airport cards
by Rob McKeever 26 Jan '02

26 Jan '02

You should be able to check the media type of the interface. I'm running on a Lombard series powerbook right now, so I can't say hat the airport card returns, but with my wirelessdriver equivalent for pccards (and, very shortly, USB devices), I at least list the various possible media types that apply and will be reporting the correct entry in a future version (lower on the list of priorities): mediumTable[] = { { kIOMediumIEEE80211None, 0 }, { kIOMediumIEEE80211Manual, 0 }, { kIOMediumIEEE80211Auto, 0 }, { kIOMediumIEEE80211DS1 | kIOMediumOptionHalfDuplex, 1 }, { kIOMediumIEEE80211DS1 | kIOMediumOptionFullDuplex, 1 }, { kIOMediumIEEE80211DS2 | kIOMediumOptionHalfDuplex, 2 }, { kIOMediumIEEE80211DS2 | kIOMediumOptionFullDuplex, 2 }, { kIOMediumIEEE80211DS5 | kIOMediumOptionHalfDuplex, 5 }, { kIOMediumIEEE80211DS5 | kIOMediumOptionFullDuplex, 5 }, { kIOMediumIEEE80211DS11 | kIOMediumOptionHalfDuplex, 11 }, { kIOMediumIEEE80211DS11 | kIOMediumOptionFullDuplex, 11 }, }; These don't match exactly with what ifconfig returns, but the labels are close enough. I think ifconfig returns strings like: DS11, Auto, Manual, etc. I'm sure somebody out there will tell me if the airport cards obey this convention as well. -Rob McKeever robm(a)mac.com Oy! The BSD/ifnet mechanisms don't currently give you that kind of detail. You'd have to get that from IOKit, and I don't know whether there is any standard way of representing wireless devices that IOKit knows about (Dean/Godfrey?). This is what 'ioreg' shows for Airport: | | | +-o radio@30000 <class AppleMacIODevice> | | | | +-o AirPortDriver <class AirPortDriver> | | | | +-o IOEthernetInterface <class IOEthernetInterface> | | | | | +-o IONetworkStack <class IONetworkStack> | | | | | +-o IONetworkStackUserClient <class IONetworkStackUserClient> | | | | +-o AirPortUserClient <class AirPortUserClient> | | | | +-o AirPortUserClient <class AirPortUserClient> 'airport' isn't going to work; and I don't know whether all wireless devices show up as 'radio'. What are you trying to do? Regards, Justin On Thursday, January 24, 2002, at 09:29 AM, Brian Wotring wrote: In my NKE, is there a way to obtain information about the network interfaces, specifically, which ones are wireless cards? -- Brian Wotring ( brian(a)shmoo.com ) PGP KeyID: 0x9674763D

1 0

Re: detaching ethernet interfaces..
by Justin C. Walker 25 Jan '02

25 Jan '02

On Friday, January 25, 2002, at 03:00 PM, Vincent Lubet wrote: On Friday, January 25, 2002, at 02:26 PM, Andrew Gallatin wrote: While I've got your attention: Do you have any plans to accommodate jumbo frames? It looks like I'm going to have to somehow override ether_inet_prmod_ioctl() to allow setting a 9000 byte mtu on my device. For now, I'm just resetting if_mtu after calling ether_ifattach(), but it would be nice to allow the user to change the mtu.. This should work as the loopback interface has a MTU of 16 KB -- the MTU is device specific. Unfortunately, this is device-specific (as you say) and in the ethernet "module" ioctl code, it rejects any attempt to set the MTU larger than ETHERMTU (1500 bytes). Therefore, if you declare yourself to be IFT_ETHER, you're stuck. I think it (the limit) should be removed, but I'll defer to wiser souls... Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | When LuteFisk is outlawed | Only outlaws will have | LuteFisk *--------------------------------------*-------------------------------*

1 0

Re: detaching ethernet interfaces..
by Vincent Lubet 25 Jan '02

25 Jan '02

Good catch, I've filed a problem report 2848646. Vincent On Friday, January 25, 2002, at 03:12 PM, Andrew Gallatin wrote: Vincent Lubet writes: On Friday, January 25, 2002, at 02:26 PM, Andrew Gallatin wrote: While I've got your attention: Do you have any plans to accommodate jumbo frames? It looks like I'm going to have to somehow override ether_inet_prmod_ioctl() to allow setting a 9000 byte mtu on my device. For now, I'm just resetting if_mtu after calling ether_ifattach(), but it would be nice to allow the user to change the mtu.. This should work as the loopback interface has a MTU of 16 KB -- the MTU is device specific. No, for an ethernet interface, mtu ioctls are caught by ether_inet_prmod_ioctl(), which does this (excuse the whitespace mangling my my mailer): case SIOCSIFMTU: /* * Set the interface MTU. */ if (ifr->ifr_mtu > ETHERMTU) { error = EINVAL; } else { ifp->if_mtu = ifr->ifr_mtu; } break; The loopback interface is not an ethernet interface, so it can have a larger mtu.. Drew

1 0

Re: detaching ethernet interfaces..
by Andrew Gallatin 25 Jan '02

25 Jan '02

Justin C. Walker writes: > > Me? Well, it's been discussed. Don't know what Apple's plans are. One > thing I've wanted to see for a long time (Jim) is a better "mbuf > cluster" implementation (Jim) that allows for variable-sized clusters. > This would make support for jumbo frames (and things like FDDI/TR) more > efficient (Jim). It'll have to wait until priorities adjust themselves, > though (Jim). That would be nice to see. We need this over the fence in FreeBSD too. I'm sick of all the drivers that contig malloc a "large" private chunk of memory & then carve it up and parcel it out... And then end up high & dry because of a large backlog on some connection... Drew

1 0

Re: detaching ethernet interfaces..
by Andrew Gallatin 25 Jan '02

25 Jan '02

Vincent Lubet writes: > > On Friday, January 25, 2002, at 02:26 PM, Andrew Gallatin wrote: > > > While I've got your attention: > > > > Do you have any plans to accommodate jumbo frames? It looks like I'm > > going to have to somehow override ether_inet_prmod_ioctl() to allow > > setting a 9000 byte mtu on my device. For now, I'm just resetting > > if_mtu after calling ether_ifattach(), but it would be nice to allow > > the user to change the mtu.. > > This should work as the loopback interface has a MTU of 16 KB -- the MTU > is device specific. No, for an ethernet interface, mtu ioctls are caught by ether_inet_prmod_ioctl(), which does this (excuse the whitespace mangling my my mailer): case SIOCSIFMTU: /* * Set the interface MTU. */ if (ifr->ifr_mtu > ETHERMTU) { error = EINVAL; } else { ifp->if_mtu = ifr->ifr_mtu; } break; The loopback interface is not an ethernet interface, so it can have a larger mtu.. Drew

1 0

Re: detaching ethernet interfaces..
by Vincent Lubet 25 Jan '02

25 Jan '02

On Friday, January 25, 2002, at 02:26 PM, Andrew Gallatin wrote: While I've got your attention: Do you have any plans to accommodate jumbo frames? It looks like I'm going to have to somehow override ether_inet_prmod_ioctl() to allow setting a 9000 byte mtu on my device. For now, I'm just resetting if_mtu after calling ether_ifattach(), but it would be nice to allow the user to change the mtu.. This should work as the loopback interface has a MTU of 16 KB -- the MTU is device specific. Vincent

1 0

Re: detaching ethernet interfaces..
by Justin C. Walker 25 Jan '02

25 Jan '02

On Friday, January 25, 2002, at 02:26 PM, Andrew Gallatin wrote: Justin C. Walker writes: On Friday, January 25, 2002, at 12:53 PM, Andrew Gallatin wrote: You mean "un-unloadable", right? Ooops, yes. My mother always told me to avoid double negatives.. ;) Yeah; best don't not use them... OK. Darn. Well, ifnet is not so big & I'd be happy to leak it. I'm not using any IOKit Network* stuff, so I'm in control & I can leak it if I need to.. Boy, everyone ought to have your attitude. Apple could sell a lot of the bigger-memory systems that way :-}. While I've got your attention: Do you have any plans to accommodate jumbo frames? It looks like I'm going to have to somehow override ether_inet_prmod_ioctl() to allow setting a 9000 byte mtu on my device. For now, I'm just resetting if_mtu after calling ether_ifattach(), but it would be nice to allow the user to change the mtu.. Me? Well, it's been discussed. Don't know what Apple's plans are. One thing I've wanted to see for a long time (Jim) is a better "mbuf cluster" implementation (Jim) that allows for variable-sized clusters. This would make support for jumbo frames (and things like FDDI/TR) more efficient (Jim). It'll have to wait until priorities adjust themselves, though (Jim). As for the MTU limit, I wonder if that's worth removing. I've always been a fan of letting the user punch as many holes in his various feet as he wishes. The lower layers ought to allow you to experiment without arbitrarily limiting you. For the nonce, you'll have to do as you suggest (override). Regards, Justin -- /~\ The ASCII Justin C. Walker, Curmudgeon-at-Large \ / Ribbon Campaign X Help cure HTML Email / \

1 0

Re: detaching ethernet interfaces..
by Andrew Gallatin 25 Jan '02

25 Jan '02

Justin C. Walker writes: > On Friday, January 25, 2002, at 12:53 PM, Andrew Gallatin wrote: > > > Is it possible to detach an ethernet interface in 10.1 / Darwin 1.4 > > after it has been ifconfig'ed up? (and down again) > > > > Eg, looking at the source code for ether_attach_inet, I see: > > > > /* XXX avoid free'ing the interface */ > > ifp->if_eflags |= IFEF_DETACH_DISABLED; > > > > I don't see IFEF_DETACH_DISABLED being cleared anywhere. So it looks > > as though an interface becomes unloadable once its been configured. > > Is this true? Why?? > > You mean "un-unloadable", right? Ooops, yes. My mother always told me to avoid double negatives.. ;) > It is true. Currently, while you can unload drivers in general, Darwin > doesn't have the necessary mechanisms to run down all the stashed copies > of the pointer to the driver's 'ifnet' structure. Therefore, if we did > allow unloading, it would likely to come back to haunt us (in the form > of a DSI, or other nasty surprise, when referencing a location that's no > longer valid in kernel memory). OK. Darn. Well, ifnet is not so big & I'd be happy to leak it. I'm not using any IOKit Network* stuff, so I'm in control & I can leak it if I need to.. While I've got your attention: Do you have any plans to accommodate jumbo frames? It looks like I'm going to have to somehow override ether_inet_prmod_ioctl() to allow setting a 9000 byte mtu on my device. For now, I'm just resetting if_mtu after calling ether_ifattach(), but it would be nice to allow the user to change the mtu.. Thanks, Drew

1 0