On Wed, Nov 19, 2014 at 09:44:56AM +0900, Simon Horman wrote:
> NMX selection method
> Signed-off-by: Simon Horman <simon.hor...@netronome.com>
Hi Simon. Sorry about the delay. Trying to catch up a little on
reviews. I'm inevitably going to fall behind next week (I'll be
traveling) but maybe I can make a few people a little happier today.
> +struct nmx_group_prop_selection_method {
> + ovs_be16 type; /* OFPGPT15_EXPERIMENTER. */
> + ovs_be16 length; /* Length in bytes of this property. */
> + ovs_be32 experimenter; /* NMX_VENDOR_ID. */
> + ovs_be32 exp_type; /* NMXT_SELECTION_METHOD. */
> + ovs_be32 pad;
> + char selection_method[NMX_MAX_SELECTION_METHOD_LEN];
> + /* Null-terminated */
> + ovs_be64 selection_method_param; /* Non-Field parameter for
> + * bucket selection. */
> + /* struct ofp11_match fields; * Fields used for bucket selection.
> + * Variable size. */
> +};
> +OFP_ASSERT(sizeof(struct nmx_group_prop_selection_method) == 40);
All of this makes sense to me except that I don't understand 'fields'
yet. Is it supposed to be a wildcard mask? I see a couple of
disadvantages with that. One is that, if it's really an OpenFlow 1.1
match, then there's no way to distinguish between, say, TCP and UDP and
SCTP ports, and one might want to do so (for example, the existing
flow_hash_symmetric_l4() uses TCP and SCTP ports but not UDP ports).
Another is that, if it's an OXM match, then one would have to define
some new rules for parsing them (prerequisites-wise, at least) so that
one could, say, list both TCP and SCTP, and both IPv4 and IPv6, and so
on. (Also, I'm not sure we have precedent for use of OXM in this way to
define a wildcard mask.)
So, my basic question is, what goes in 'fields'? Probably with a few
examples to make the pattern clear.
Thanks,
Ben.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
