Darren Reed writes: > James Carlson wrote: > > So, if there's a separate net_data_t for each exclusive IP stack > > instance, how do you find it? > > What's missing in the documentation is that the interface is: > net_protocol_lookup(netid_t, char *)
Ah! OK, that fixes the problem. > How do you discover the netid_t? > At present, as a result of being called from the > _create() when you do a net_instance_register() > or use GLOBAL_NETID. It seems a shame that every client that understands zones needs to keep its own list of the active zones around, but I guess I see why it works that way. > > The problem I see is that it's unclear when and if the consumer of > > pfhooks has access to zone information. I understand that it may be > > the case that some hooks can't provide this, but that others can, but > > I don't think that the consumer of pfhooks should need to understand > > how the hooks themselves are implemented -- the existence of zone > > information should be called out where it is known. > > Ok. To make this easier, I can add these two: > netid_t net_zoneidtonetid(zoneid_t) > zoneid_t net_netidtozoneid(netid_t) > > This, along with "netid_t net_getnetid(net_data_t)" > should provide enough information to find out which > zone you're in when doing processing on a packet > from an event. OK; yes, that looks like it does the trick. > It is tempting to add net_data_t to the hook_*_event_t, > so that the proper context is always available, rather > than require the consumer to store this themselves. I think it's likely that clients will need to be able to go from a given netid_t to some sort of internal state structure. That's the one where I see potential usage trouble. > And if you're finding it hard, so will others... putting > the context that a hook is executed in into the hook data > structures is starting to seem like a very worthwhile low > cost win here. Yes. > >>> Is it possible to invoke L2 (ARP/NDP) look-up? > >> Not through this interface, no. > > > > I think this was one of the SDP/IB requests, so that's why I was > > asking. > > It is something that could potentially be added - > I don't see anything that exists now getting in the > way of it. But I'd rather wait until they were > knocking on the door (they aren't yet) and they > knew exactly what interface they required. OK. > > I'm not so sure I agree with "X wants to be first" translating into > > "Q->X" in the stack. I'm not even sure I understand what "first" > > means in those circumstances. Depending on load order, which doesn't > > seem defined, it seems that a module specifying "first" could silently > > be placed last after a long list of other modules. > > ... > > Suppose there > > *are* two such products. Aren't they incompatible with each other? > > Why not prevent incompatible products from being loaded > > simultaneously? > > If each wants to access unmodified packets that come from > the hook, then yes, they are incompatible if either one > changes the packet. > > I think an extension that needs to be examined in more > detail is what does it mean if a hook consumer says "I > won't modify the packet"? But I'd like to take that on > as an extension of the existing work rather than try fold > that in now. It seems at least a bit related to this "first" and "last" business. I agree that one plausible interpretation of "first" is that it actually means "no packet-modifying things will be placed before me in the list" and "last" similarly means "no packet-modifying things will be placed after me." > > I have no problem with that. The relative ordering makes sense, and > > an intermediate module doesn't bother me. Instead, I'm confused about > > the absolute ordering that's not really absolute. > > ... > > I'd answer that by saying that since they've both demanded to be > > first, and only one can actually be first, then one must lose. As > > long as that's a constraint listed in the documentation, and that > > hook-using module writers explain to their customers, I don't see it > > as a big problem. > > ... > > I don't want to admit it, but you do have a point here with > the argument you've put forward. ;-} > One approach might be to recommend that developers design to > operate "at any point in the list" and that if an attempt to > insert a hook with a hint of first/last fails (because it is > already being used), they should retry without a hint. I agree that technique would provide the sort of fall-back capability needed, but if you were actually prepared to operate anywhere in the list from the beginning, why would you ask specifically to go first or last? I think that question is related to the original one: "if you asked to go first in the list, and the system silently puts you somewhere else, is that a bad thing?" I don't quite know the answer to that one. > Something that I haven't taken into account (and that I need > to) is what happens if X must be before Y, but you try to > remove Y before X? I think this is clearly an operation that > must be denied: so long as there is a dependency on a hook, > it can't be removed from the list. At least as I understood these ordering dependencies, I wouldn't have expected that to happen. Instead, I'd expect that if X must be before Y, then that ordering matters as long as Y is present. If Y isn't present, or if Y disappears, then the ordering request has no effect. What you're suggesting seems like a bit of a trap. I can add X and remove it with no trouble. I can add Y and remove it. But if I add X and Y, and then try to remove Y, I'm now stuck and am forced to remove X. I think what you're trying to accomplish here is *more* than just ordering. You're actually talking about functional or operational dependencies: one hook uses the output of another, and Bad Things will happen if the dependency is broken without somehow synchronizing. That's getting really close to Solaris STREAMS _I_INSERT and _I_REMOVE in terms of functionality. It's a bit hazardous, unless there's some sort of design feature (a "dependency is leaving" callback, perhaps) that allows the modules themselves to get in on the game. I'm not sure I understand what the usage case for such a thing would be, though. > > ... > > Dumb question time: this is all global, right? You can't have > > per-interface hook lists, or per-exclusive-IP-stack hook lists, right? > > You can have per-exclusive-IP-stack hook lists. > Shared IP stack zones are bound to whatever happens > in the global zone. OK. I was still assuming that net_data_t was global, because of the net_protocol_register arguments. Per-stack makes sense here. > The hooks are now (and will continue to be) specific > to each instance of IP. > > The easy example today is to have (say) the global zone > with ipfilter enabled and a local zone that has an exclusive > stack instance with ipfilter disabled. > > In the global zone, the physical-in/physical-out hook > lists will have ipfilter on them and in the local zone, > they'll be missing. Seems fine; I was just checking that I understood the boundaries. In the future, you might want to consider whether per-interface hooks make sense. I suspect that it'll be a performance issue if the hook consumers each have to check whether they care about the interface first before doing anything else. In other words, if you had (say) a 10/100 "hme0" interface with a pile of hooks enabled for various purposes, you might not also want to have the system running through the same set of hooks for your 10Gbps "xge0" interface. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 35 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]
