[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJ3xEMh-76WMatuknjywQK=ZVWG8UM5swEC0CE5FTv-ts-Jk6g@mail.gmail.com>
Date: Mon, 15 Sep 2014 20:03:38 +0300
From: Or Gerlitz <gerlitz.or@...il.com>
To: Tom Herbert <therbert@...gle.com>
Cc: David Miller <davem@...emloft.net>,
Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: [PATCH v2 net-next 3/7] fou: Add GRO support
On Mon, Sep 15, 2014 at 6:10 PM, Tom Herbert <therbert@...gle.com> wrote:
> On Mon, Sep 15, 2014 at 8:00 AM, Or Gerlitz <gerlitz.or@...il.com> wrote:
>> On Mon, Sep 15, 2014 at 6:07 AM, Tom Herbert <therbert@...gle.com> wrote:
>>> Implement fou_gro_receive and fou_gro_complete, and populate these
>>> in the correponsing udp_offloads for the socket. Added ipproto to
>>> udp_offloads and pass this from UDP to the fou GRO routine in proto
>>> field of napi_gro_cb structure.
>>
>>
>> Do we really need that extra hop of fou4_gro_receive/complete?
>> can't we somehow plant the gro receive/complete (say) GRE handlers in
>> the udp offload
>> struct with the UDP port that related to (say) GRE over UDP tunneling?
>>
> That would be nice, but it isn't obvious to me how to manage the
> references. The offload functions are accessed with RCU pretty consistently.
Currently udp_gro_receive calls rcu_read_lock() before it invokes
fou4/6_gro_receive
and rcu_read_unlock after the fou calls returns. The Fou call repeats
the same practice
w.r.t the (say) GRE gro receive callback, so... what happens if we
eliminate the fou part all together?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists