Erik Nordmark writes: > Jim, > > > It may also be possible to remove the need for DLPI for IPv4, and > > incidentally simplify the code a fair amount, by adding a kernel > > option to allow transmission and reception of UDP packets over > > interfaces that are plumbed but not marked IFF_UP. This is left for > > future work. > > How aggressively do you think we should try to get the use of DLPI out > of dhcpagent?
I think it's distasteful, but I'm not about to commit any time to work on it, if that's what you mean. ;-} If there's some other project that's actually harmed by DLPI usage for DHCP (say, packet filtering or tracing within IP that isn't aware of this little bypass road), then that would be a good reason to attack it with more effort. > We would need to revise how IP determines to bring up its DLPI provider > (DL_ATTACH_REQ, DL_BIND_REQ) which today doesn't happen until the > interface is both IFF_UP and has a non-zero IPv4 address. But we could > potentially do this immediately when ifconfig plumb happens. (Doing it > at plumb time might also help us simplify the locking in IP; less of a > need for ILL_CHANGING if we do the DLPI attach and bind e.g. when > handling the SIOCSLIFNAME ioctl; we can defer inserting the ill in the > global list of ills until this point in time.) We could simplify even more radically if we pulled the DLPI set-up dance entirely into user space, and got IP out of this business, but that'd unfortunately break if_tcp(7P). As for ILL_CHANGING, I'm not sure about that one. It looks to me like that's set as part of the SIOCSLIFLNKINFO handling, and that seems to be some delicate logic involving both ILL_CAN_LOOKUP and ire_add. I don't quite see how changing the DLPI timing would help with that. It's also used with the IPMP logic, and until meem redoes this for his project, I don't think that part will be easy to touch. > Once IP has the DLPI stream in place, then IP_XMIT_IF, IP_NEXTHOP, etc > should be able to send packets by just specifying the interface index. Yes. But output is easier than input. For input, we need to have some way of receiving a packet when there's no matching IRE_LOCAL but there's an interested socket. We have no way of doing that today. -- James Carlson, KISS Network <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
