Re: [PATCH net-next V2 1/3] net: Add GRO support for UDP encapsulating protocols

[Or Gerlitz <ogerlitz@mellanox.com>]

On 08/01/2014 01:04, Tom Herbert wrote:
> On Tue, Jan 7, 2014 at 12:21 PM, Or Gerlitz<or.gerlitz@gmail.com>  wrote:
>> >On Tue, Jan 7, 2014 at 8:44 PM, Tom Herbert<therbert@google.com>  wrote:
>>> >>Or, thanks for posting the patches!
>>> >>
>>> >>We should also support the case where direct encapsulation is being
>>> >>done, that is there is no encapsulation header after UDP and the
>>> >>protocol of the encapsulated packet is inferred by the port number
>>> >>(e.g. GRE/UDP, TCP/UDP, SCTP/UDP, etc.). This is probably an
>>> >>additional field in net_offload struct for next protocol, a little
>>> >>more API, and pretty trivial handlers in UDP code.
>> >
>> >The way I have set that follows your guideline under which the
>> >encapsulating method is derived from the udp destination port in the
>> >sense that the encapsulating protocol can do what they want in the
>> >gro_receive/complete handlers entry they plant per that udp port,
>> >isn't that generic enough?
> Direct encapsulation of different protocols could be done using the
> same callback functions. Somehow, we just need to pass the protocol
> number (or more generally pass private data to the callbacks). In lieu
> adding this to net_offload, we could just make the net_offload an
> argument to the callbacks and use container_of to access a private structure.
>

Tom,

OK, so I understand that you want the infrastructure to allow for direct 
udp encapsulation in the sense that there is no specific encapsulation 
header following the udp header.

Take for example encapsulating TCP over UDP port X, the layer/driver 
that wants to enable gro for such traffic will register a udp gro 
handler for port X and in their gro receive/complete
callbacks would just assume that following the UDP header there's TCP 
header and they will then issue a lookup in the inet gro handlers array 
to get the TCP gro handler, problem solved, agree?

Or.