[ovs-discuss] [PATCH-RFC 1/2] Improve ARP latency

Jesse Gross jesse at nicira.com
Wed Oct 7 02:16:43 UTC 2015


On Tue, Oct 6, 2015 at 2:42 PM,  <dwilder at us.ibm.com> wrote:
>
> Quoting dwilder at us.ibm.com:
>>>
>>>
>>> On the patch itself, can't we just make skb_get_hash() be able to
>>> decode ARP? It seems like that is cleaner and more generic.
>>
>>
>> My first thought was to make a change in skb_get_hash().  However, the
>> comment in __skb_get_hash() state that the hash is generated from the
>> 4-tuple (address and ports).  ARPs have no ports so a return value of 0
>> looked correct.
>>
>> /*
>>   * __skb_get_hash: calculate a flow hash based on src/dst addresses
>>   * and src/dst port numbers.  Sets hash in skb to non-zero hash value
>>   * on success, zero indicates no valid hash.  Also, sets l4_hash in skb
>>   * if hash is a canonical 4-tuple hash over transport ports.
>>   */
>>
>> What do you think?
>>
>
>
> Hi Jesse
>
> I did not get a response so I was unsure how to proceed.
>
> I am willing to pursue enhancing skb_get_hash() if you think that is the
> best approach.  However what would you think of something like this?
>
> hash = skb_get_hash(skb);
> if ( ! hash )
>        return ids->ids[vport->port_no%ids->n_ids];
>
> return ids->ids[hash - ids->n_ids * reciprocal_divide(hash, ids->rn_ids)];
>
> This would solve my problem on kernels without the enhanced skb_get_hash()
> and no further change to ovs would be required once shb_get_hash() is
> updated.

OVS has an extensive system of backports from newer kernels. You
should strive to get your changes accepted in the upstream Linux tree
and then they can be backported to the OVS out-of-tree kernel module
for existing kernels.

> PS:  Should I move this discussion to ovs-dev ?

It would have been a better place to start it but it doesn't really
matter at this point.



More information about the discuss mailing list