Erik Nordmark wrote: > [EMAIL PROTECTED] wrote: > >> One of the more interesting problems we have with OpenSolaris' >> networking is that the structure and contents of the mblk seem >> to be fixed (for all time.) >> >> This is somewhat at odds with evolving networking in OpenSolaris >> as there's an invariant here that is limiting us. At least two >> projects have contested for the right to use part of the few >> remaining bits in the flag field and without doubt there will >> be more. >> >> Why do people want to use flag bits? Because it's the only way >> to store a single bit of "private" data on the mblk and have it >> be carried forward... >> >> Which brings is to the problem. >> >> For people that want to build on top of OpenSolaris, there is >> no way to attach private "meta-data" to a packet as it enters >> the system on one interface and be able to retrieve it as it >> exists the system on another. We need the means to do this. > > > I don't think the above description is sufficient to figure out what > approach might make sense. There can be many different meanings of > "carried forward" above. A few possibilities are: > - Some part of TCP/IP wants to set something that another part of > TCP/IP wants to look at, i.e., it is local to TCP/IP. > - The thing should be carried forward from a receive packet to a > transmitted packet as part of forwarding. > - Carry it to TCP/SCTP and they will use it for sending subsequent > packets. > - Carry it to the application so that it can potentially use it for > other communication. > - Some plugin mechanism in the stack should allow for 3rd parties to > write "modules" that can both set meta-data and check it i.e., the 3rd > party provides different modules that plug into different parts of the > stack. (Note that we don't really have such a plugin mechanism today - > apart from STREAMS modules.)
Even though STREAMS supports a plugin mechanism today, there's no capability for a STREAMS module to attach some meta data to a packet on the way up into IP and retrieve it when the packet comes back down. > The first case is fairly well understood, and can be handled by > defining some attribute data structure which is passed as procedure > call arguments instead of as something tied to the > mblk/message/packet. (And IP Datapath Refactoring is planning to do > exactly that to get rid of prolific M_CTL usage, ip6i_t, etc.) > > For the last case, if we define a plugin mechanism, for the meta data > to be useful we would also need to carefully specify where that meta > data is carried transparently and where it is not. > For instance, would or would not udp_rput be required to pass up the > meta data so that a "module" above could inspect it? > Would a kernel socket API have to pass it up? I hadn't considered either of these two scenarios. In the requirements I've seen so far, there is no requirement for the meta data to follow the data itself. > Should TCP use it for response traffic or not? > What about forwarding. For packets being forwarded through the kernel, meta data that is attached to a packet should be preserved until either the packet is freed/discarded (this includes after it is sent out of the NIC) or the owner disposes of it (it/when they see it again). Darren _______________________________________________ networking-discuss mailing list [email protected]
