On Mon, Jul 14, 2008 at 3:56 PM, J. Bruce Fields <[email protected]> wrote:
> On Fri, Jul 11, 2008 at 03:11:29PM -0400, Chuck Lever wrote:
>> On Fri, Jul 11, 2008 at 2:40 PM, J. Bruce Fields <[email protected]> wrote:
>> > On Thu, Jul 10, 2008 at 01:27:47PM -0400, Chuck Lever wrote:
>> >>
>> >> On Jul 7, 2008, at 4:51 PM, Trond Myklebust wrote:
>> >>
>> >>> On Mon, 2008-07-07 at 15:44 -0400, Chuck Lever wrote:
>> >>>
>> >>>> If you would like connected UDP, I won't object to you implementing
>> >>>> it. However, I never tested whether a connected UDP socket will give
>> >>>> the desired semantics without extra code in the UDP transport (for
>> >>>> example, an ->sk_error callback). I don't think it's worth the
>> >>>> hassle
>> >>>> if we have to add code to UDP that only this tiny use case would
>> >>>> need.
>> >>>>
>> >>>
>> >>> OK. I'll set these patches aside until I have time to look into adding
>> >>> connected UDP support.
>> >>
>> >> That's not completely necessary... the one-shot + TCP changes just make
>> >> it nicer when the local rpcbind is not listening. Without these, the
>> >> cases where the rpcbind daemon isn't running, or doesn't support rpcbind
>> >> v3/v4 and the kernel was built with CONFIG_SUNRPC_REGISTER_V4, will cause
>> >> some delays before failing, but otherwise shouldn't be a problem.
>> >>
>> >> I think you can drop the patch to change rpcb registration to go over
>> >> TCP for now unless you already have a CUDP implementation you are happy
>> >> with.
>> >
>> > So actually in your original series of 7 I think that'd mean dropping
>> > numbers 5 and 6 and keeping the rest?
>>
>> So, 5/7 adds "one shot" support to the RPC client. I think that might
>> be interesting for other kernel services, like making rpcbind queries
>> over TCP, or NFSv4 callback. I'd like to advocate for keeping that
>> one so others can build on it (with whatever name for the create flag
>> we can agree on), but it's not really necessary for subsequent
>> patches.
>>
>> 6/7 changes the rpcb_register logic to use "one shot" + TCP -- that's
>> the one that is controversial and can be dropped.
>
> May as well at least apply the other 5? Trond is carrying other
> net/sunrpc/rpcb_clnt.c patches, so they probably need to go in his tree.
>
> I guess I'll go ahead and send along versions based on latest
> trond/devel.
Yep, it's reasonable to get these circulating to ensure they don't
cause any unwanted side effects for standard rpcbindv2/IPv4 usage.
We just need to take care these don't get too badly re-ordered when
merging all this back together when 2.6.27 opens.
--
Chuck Lever