Hi William,
Comments inline.
On 7/12/16, 12:06 PM, "William Tu" <u9012...@gmail.com> wrote:
>Hi Wenyu and Daniel,
>
>Thanks for your feedback.
>
>On Mon, Jul 11, 2016 at 1:50 AM, Wenyu Zhang <wen...@vmware.com> wrote:
>> Hi William,
>>
>> In your patch, no codes about supporting ³snaplen" in IPFIX included.
>>IPFIX
>> still get the length of packet as before, whatever the packet is
>>truncated.
>> If user put a non-zero Œsnaplen¹ in IPFIX sample action, the IPFIX
>>result
>> should be incorrect. So the Œsnaplen¹ in the flow-based IPFIX action may
>> cause some issue without the complete supporting.
>
>You're right. If IPFIX wants to use the snaplen feature, then the
>IPFIX implementation needs to be aware of receiving a truncated packet
>instead of the original packet. Much similar to the change I made in
>ofprot-dpif-sflow.c.
>
>>
>> Considering that Œsnaplen¹ may help reduce the cost to copy packets, it
>> should help IPFIX too. We may work out a separated patch to support
>> ³snaplen² in IPFIX, including both bridge based IPFIX and flow based
>>IPFIX.
>>
>
>Skimming through the IPFIX RFC, I don't have any concrete idea which
>IPFIX configuration could translate to the snaplen, or how IPFIX could
>use snaplen. For sFlow, it's straightforward because it has
>"sFlowMaximumHeaderSize" which could directly translate to snaplen. Do
>you have any suggestion?
Wenyu: Yes, IPFIX RFC doesn¹t require snaplen. We just think that the
³snaplen²
may help us reduce the un-necessary cost when running IPFIX on OVS.
According your comments, the ³snaplen² may truncate the packet, so
not
the whole packet, but only the truncated part will be copied to
userland,
is that true? If so, IPFIX may use it to reduce the cost of copying
packet,
due to that IPFIX is only interested at the headers of the packet,
not
the whole packet.
In fact, ³snaplen² for IPFIX is just a proposal optimisation for
performance.
>
>Regards,
>William
Bests,
Wenyu
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
