James Carlson wrote: > Darren Reed writes: >> James Carlson wrote: ... >> 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.
Ok; I've added "net_data_t hpe_family" to hook_pkt_event_t which serves the same role as "net_data_t hne_family" in hook_nic_event_t. >>> 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." > > >> 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. Or if you ask to be last and someone else says they want to be after you (rather than just "last"), should that be denied? (And there's a similar case for "first" as well.) I think in both of those cases, there shouldn't be an error or a problem: clearly the one requesting to be before/after the first/last entry should be cognisant of the expections. >> 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. Actually no, and I can't believe I didn't mention this - at least in net_hook_register(). If a hint cannot be satisfied at insertion time, the registration fails. If X must be before Y and there is a hint asking for this, then if Y isn't there, registering X will fail. > 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. Yes. > 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. Well, what I'm hearing from people is that they definitely want to be able to say they're before or after ipfilter. In some cases, what is being developed expects ipfilter to be in the middle, whether ipf is just doing the redirect work or firewall or whatever else. So if ipfilter was allowed to disappear while its dependents still existed then I'd expect something to go wrong - what I can't say. I think I'd call this a "strong binding" behaviour and one where a hook was allowed to disappear (when it has dependents) "weak binding." For now I'd like to concentrate on "strong binding" and come back to something that allows for "weak binding" (where you might have a callback to inform you that your dependency is now broken.) ... > 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. Yup, I'm with you on that. And yes, that would be a future thing :) Thanks, Darren _______________________________________________ networking-discuss mailing list [email protected]
