[ovs-dev] [PATCH 1/2] ofp-actions: Add the NXAST_SAMPLE vendor action

Romain Lenglet rlenglet at vmware.com
Tue Dec 11 19:17:33 UTC 2012


On Dec 11, 2012, at 10:47 AM, Ben Pfaff <blp at nicira.com> wrote:

> 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 <rlenglet at 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.)

Thanks for your comments.
Sorry for not providing more context earlier.

The intent is to send an IPFIX packet for every sampled packet.
It won't be sent to the controller, but to an IPFIX collector.

It will be similar to the existing packet sampling implementation, but sampling will be done at flow granularity and controlled by the controller by inserting such explicit sampling actions.

> 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.

The restriction of sampling actions to the beginning of an action list is to ensure that the packets sent via IPFIX have not yet been modified in the particular flow containing the sampling actions.
IPFIX supports reporting a packet's headers both before and after rewriting, e.g. in the sourceMacAddress and postSourceMacAddress fields, and I intend to report only the pre-rewriting headers for now.

I think the behaviour with resubmit would be fine.
I only want the IPFIX packets to reflect the sampled packet's headers before modification by any actions in the flow containing the sampling action.

I don't understand your comment about "correct metadata."
Which metadata are you thinking about?

The sampling action cookie contains all the metadata I need.
To create and send an IPFIX packet I only need:
- an IPFIX collector's IP address and port, which will be globally configured;
- an IPFIX observation domain ID (unsigned 32-bit), which I will associate via the configdb with every datapath;
- an IPFIX observation point ID (unsigned 32-bit), contained in the sample action cookie;
- the sampled packet headers.
I don't need any other data.

> 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?




More information about the dev mailing list