OK, got it.
At some point we'll want to look up the tunnel meta-data for all sampled
packets so we can fill in the sFlow tunnel annotations too
(http://sflow.org/sflow_tunnels.txt) but that is a separable step. In the mean
time it seems OK that the conjured "packet-out" actions might not populate
every sFlow field.
Revised patch to follow.
Neil
On Apr 29, 2013, at 3:35 PM, Jesse Gross wrote:
> 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
