On 10/17/16, 5:17 PM, Roopa Prabhu wrote:
> On 10/17/16, 3:10 AM, Jamal Hadi Salim wrote:
[snip]
inline below more data/context..
>>>> +
>>>> +struct sample_packet_metadata {
>>>> + int sample_size;
>>>> + int orig_size;
>>>> + int ifindex;
>>>> +};
>>>> +
>>> This metadata does not look extensible.. can it be made to ?
>>>
>> Sure it can...
more sflow context here... [1]
An extensible metadata scheme is highly desirable when passing data from the
dataplane to
the sampling agent in userspace. Looking forward, advanced instrumentation is
being
added to data planes and keeping the api future proof will help.
>>
>>> With sflow in context, you need a pair of ifindex numbers to encode ingress
>>> and egress ports.
>> What is the use case for both?
> I have heard that most monitoring tools have moved to ingress only sampling
> because of operational
> complexity (use case is sflow). I think hardware also supports ingress and
> egress only sampling.
> better to have an option to reflect that in the api.
The reason for having two ifindex numbers is to record the ingress and egress
ports (i.e. the path that the packet takes through the datapath/ASIC). You may
actually have three ifindex numbers associated with a sample:
1. The data source that made the measurement (on a linux system each bridge has
its own ifindex)
2. The ifindex associated with the ingress switch port
3. The ifindex associated with the egress switch port.
All three apply irrespective of sampling direction.
thanks,
Roopa
[1] Additional extended flow attributes have been defined to further extend
sFlow packet samples:
http://sflow.org/sflow_tunnels.txt <http://sflow.org/sflow_tunnels.txt>
http://sflow.org/sflow_openflow.txt <http://sflow.org/sflow_openflow.txt>
