On Tue, Dec 11, 2012 at 09:54:50AM -0800, Romain Lenglet wrote: > Define NXAST_SAMPLE OpenFlow vendor action and the corresponding > OFPACT_SAMPLE OVS action. > > Signed-off-by: Romain Lenglet <rleng...@vmware.com>
I think that this new action is intended to send the packet to a controller when sampling happens, and to allow the packet to "pass through" to additional actions whether it is sampled or not. (The patch doesn't document the intent well enough for me to be certain, and the full implementation isn't here.) I'm a bit worried about some implementation details. I guess that the restriction to the first action in a flow is to ensure that userspace can supply correct metadata, but I don't think that's sufficient because "resubmit" can cause the first action to be in the middle of the final action set. It would be better, of course, if it was not necessary to have such restrictions. That poses the question of how to avoid it. One solution would be to have userspace implement such a flow as a "slow path" all the time, but that would be, of course, slow for high-bandwidth flows, and we don't want that. Another solution would be to have userspace implement all the actions for such a flow, but only for packets that are sampled, and have the un-sampled packets handled directly by the kernel. That sounds attractive at first but it would cause random packet reordering which is a nasty side effect. The best solution might be to keep a table in userspace that matches up the send-to-userspace 64-bit cookie values with metadata, so that the datapath could send packets to userspace and have userspace identify the metadata correctly while still processing the packets at full kernel rate in the datapath. That requires a bit of effort. Your thoughts? _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
