All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chuck Lever <chuck.lever@oracle.com>
To: Jeff Layton <jlayton@redhat.com>
Cc: linux-nfs@vger.kernel.org, nfsv4@linux-nfs.org
Subject: Re: [PATCH 3/6] nfs-utils: skip getaddrinfo in create_auth_rpc_client unless we need port
Date: Wed, 1 Apr 2009 14:01:30 -0400	[thread overview]
Message-ID: <32D01620-325D-4D82-81EF-8584134BC7DC@oracle.com> (raw)
In-Reply-To: <20090401134739.01b72029@barsoom.rdu.redhat.com>

On Apr 1, 2009, at 1:47 PM, Jeff Layton wrote:
> On Wed, 1 Apr 2009 13:11:04 -0400
> Chuck Lever <chuck.lever@oracle.com> wrote:
>>
>> On Apr 1, 2009, at 10:24 AM, Jeff Layton wrote:
>>> We already have the server's address from the upcall, so we don't
>>> really
>>> need to look it up again. Move the getaddrinfo call in
>>> create_auth_rpc_client to a new function. Skip it if we already have
>>> the
>>> port in the sockaddr that we saved from the info in the upcall. If
>>> we need to get the port, don't bother looking up the hostname,  
>>> just do
>>> the getaddrinfo with AI_NUMERICHOST set.
>>>
>>> This should reduce the amount of lookups that are needed.
>>>
>>> Signed-off-by: Jeff Layton <jlayton@redhat.com>
>>> ---
>>> utils/gssd/gssd_proc.c |  134 ++++++++++++++++++++++++++++
>>> +-------------------
>>> 1 files changed, 81 insertions(+), 53 deletions(-)
>>>
>>> diff --git a/utils/gssd/gssd_proc.c b/utils/gssd/gssd_proc.c
>>> index f5f3a0f..4d54c40 100644
>>> --- a/utils/gssd/gssd_proc.c
>>> +++ b/utils/gssd/gssd_proc.c
>>> @@ -538,6 +538,76 @@ out_err:
>>> }
>>>
>>> /*
>>> + * Determine the port from the servicename and set the right field
>>> in the
>>> + * sockaddr. This is mostly a no-op with newer kernels that send
>>> the port
>>> + * in the upcall. Returns true on success and false on failure.
>>> + */
>>> +static int
>>> +populate_port(struct sockaddr *sa, char *servicename, int socktype,
>>> +	      int protocol)
>>
>> I think you can guess the socktype from the protocol setting, so  
>> maybe
>> you don't need @socktype.  Actually, for AI_NUMERICHOST I don't think
>> protocol and socktype are even relevant.
>>
>
> It seems to me that getaddrinfo() needs to have some way to know
> whether you want the tcp or udp port for the service. I'm not sure
> whether it uses the ai_socktype or ai_protocol to determine this
> (probably the protocol), but I figure it doesn't hurt to set both.

As far as I understand it, the ai_socktype and ai_protocol fields are  
used to return the values needed for subsequent socket(2)/bind(2)  
system calls.  In this case you are not using these fields from the  
results...

If ai_protocol is zero, then getaddrinfo(3) assumes you want one copy  
of the address for each supported protocol type, so it returns three  
structures (one for IPPROTO_UDP, one for IPPROTO_TCP, and one with a  
zero protocol number).  The contents, except for the socktype and  
protocol fields, are the same for each.

You're using only the port number in the socket address, and ignoring  
the other contents.  So, yes, it works the same anyway, but it's  
confusing to read all the extra logic in populate_port().

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

  reply	other threads:[~2009-04-01 18:01 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-01 14:23 [PATCH 0/6] nfs-utils: convert gssd to TI-RPC and add IPv6 support (try #2) Jeff Layton
2009-04-01 14:24 ` [PATCH 1/6] nfs-utils: make getnameinfo() required for --enable-gss Jeff Layton
2009-04-01 14:24 ` [PATCH 2/6] nfs-utils: store the address given in the upcall for later use Jeff Layton
2009-04-01 16:58   ` Chuck Lever
2009-04-01 17:06     ` Jeff Layton
2009-04-01 17:14       ` Chuck Lever
2009-04-01 14:24 ` [PATCH 3/6] nfs-utils: skip getaddrinfo in create_auth_rpc_client unless we need port Jeff Layton
2009-04-01 17:11   ` Chuck Lever
2009-04-01 17:47     ` Jeff Layton
2009-04-01 18:01       ` Chuck Lever [this message]
2009-04-03 19:04         ` Jeff Layton
2009-04-06 15:03           ` Chuck Lever
2009-04-06 15:21             ` Jeff Layton
2009-04-06 15:46               ` Chuck Lever
2009-04-06 16:33                 ` Jeff Layton
2009-04-06 22:33                 ` Kevin Coffman
2009-04-06 22:59                   ` Chuck Lever
2009-04-01 14:24 ` [PATCH 4/6] nfs-utils: split out gssd rpc client creation into separate function Jeff Layton
2009-04-01 14:24 ` [PATCH 5/6] nfs-utils: when TIRPC is enabled, use new API to create RPC client Jeff Layton
2009-04-01 17:23   ` Chuck Lever
2009-04-01 14:24 ` [PATCH 6/6] nfs-utils: add IPv6 code to gssd Jeff Layton
2009-04-03 16:07 ` [PATCH 0/6] nfs-utils: convert gssd to TI-RPC and add IPv6 support (try #2) Steve Dickson
     [not found]   ` <49D63436.8010709-AfCzQyP5zfLQT0dZR+AlfA@public.gmane.org>
2009-04-03 17:00     ` Jeff Layton
  -- strict thread matches above, loose matches on Subject: below --
2009-03-11 16:42 [PATCH 0/6] nfs-utils: convert gssd to TI-RPC and add IPv6 support (RFC) Jeff Layton
2009-03-11 16:42 ` [PATCH 3/6] nfs-utils: skip getaddrinfo in create_auth_rpc_client unless we need port Jeff Layton
2009-03-11 22:09   ` Chuck Lever
2009-03-12 21:48     ` Jeff Layton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=32D01620-325D-4D82-81EF-8584134BC7DC@oracle.com \
    --to=chuck.lever@oracle.com \
    --cc=jlayton@redhat.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=nfsv4@linux-nfs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.