On Mon, Apr 29, 2013 at 2:53 PM, Neil Mckee <neil.mc...@inmon.com> wrote:
> but I'm not sure I understand the one in tunnel.c. I assume you mean this
> comment:
>
> /* XXX:
> *
> * Ability to generate metadata for packet-outs
> * Disallow netdevs with names like "gre64_system" to prevent collisions. */
>
> Is this referring to the code that appears 60 lines later? i.e. this test
> here:
>
> existing_port = tnl_find_exact(&tnl_port->match);
> if (existing_port) {
> if (warn) {
> struct ds ds = DS_EMPTY_INITIALIZER;
> tnl_match_fmt(&tnl_port->match, &ds);
> VLOG_WARN("%s: attempting to add tunnel port with same config as "
> "port '%s' (%s)", tnl_port_get_name(tnl_port),
> tnl_port_get_name(existing_port), ds_cstr(&ds));
> ds_destroy(&ds);
> free(tnl_port);
> }
> return &void_tnl_port;
> }
>
> And is the concern related to filling in the output-port correctly in sFlow
> samples? Using that scheme where the output-port is stored in a per-flow
> cookie and retrieved later when a sampl e is taken? If I have understood
> correctly, you might have "collisions" where the tunnel netdev name is the
> same for two tunnels even if the ultimate datapath output port is going to be
> different. And so the revised comment should explain that if that happens
> the sFlow output port is not going to be filled in, and will instead be
> reported as either 0=="unknown" or 0x80000001=="one interface". Did I get
> that right?
Actually, these are two separate items in the XXX list. I was
referring to the first one and I think you can just delete it.
Packets sent using the OpenFlow "packet out" mechanism can appear to
come from any OpenFlow port, including tunnels. However, the only way
to distinguish between those ports at the datapath level is to have
the associated tunnel metadata (like source and dest IPs). Normally,
this wouldn't matter because nothing cares about the input port of
packets that are about to be output (since we already know the actions
to execute) - except sFlow. The idea was to simulate the metadata so
that when sFlow did a lookup it would find the correct OpenFlow port.
However, none of that matters if sFlow is just going to report the
port as unknown.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
