On 4/8/15 8:11 PM, Lizhong Jin wrote:
[Lizhong] If the NVE and tenant is integrated into one device, then the issue
could
be solved by implementation. Because tenant know the entropy value of the first
segment, and use the same value to the subsequent segment. So different
implementation model could provide different entropy value. Or do we need other
mechanism to mitigate this issue, e.g., fragment on NVE in
draft-herbert-gue-fragmentation.
Lizhong,
My point was more fundamental. Today on the Internet there are routers
which do hashing for LAG or ECMP purposes. They have the same issues
with fragmented packets.
For section 18.1.1, I suggest RFS should be analyzed. E.g., if NIC
want to do flow steering based on the inner header information, then
it could use entropy value instead of the inner header information.
Did you mean Receive Side Scaling (RSS)? That is mentioned in the document -
section 18.1.1 . Perhaps the RSS text can be improved.
Receive Flow Scaling is the name of a Linux software technique to take into
account the CPU on which the application is running, which is different.
[Lizhong] I am referring to hardware based flow steering, similar with
Accelerated
RFS (Receive Flow Steering). In the NIC I/O virtualization, the NIC will
directly trigger
interrupt to the CPU where application is running by looking up a flow table.
We will
use the inner header to do the flow table lookup, if hardware could not parse
the
inner header, then entropy value in the encapsulation is required. Any design of
hiding inner header information should consider above implementation.
I thought the purpose of RFS was to send the packet (and associated
interrupt) to the CPU where the application process is running. That
implies an exact flow lookup. Some hash value, whether computed by the
receiving NIC or whether in some entropy field in the packet (computed
by the sender or encapsulator) would not suffice for that purpose.
Of course, a hash value (e.g., from the entropy field) is useful for RSS.
Regards,
Erik
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
