All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Emelyanov <xemul@parallels.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: "J. Bruce Fields" <bfields@fieldses.org>,
	Trond Myklebust <Trond.Myklebust@netapp.com>,
	linux-nfs@vger.kernel.org
Subject: Re: [PATCH 1/7] sunrpc: Factor out rpc_xprt allocation
Date: Tue, 28 Sep 2010 20:51:19 +0400	[thread overview]
Message-ID: <4CA21D07.4070900@parallels.com> (raw)
In-Reply-To: <10FA0502-F580-460A-BADC-9AEEA7ADE4A3@oracle.com>

>> +struct rpc_xprt *xprt_alloc(int size, int max_req)
>> +{
>> +	struct rpc_xprt *xprt;
>> +
>> +	xprt = kzalloc(size, GFP_KERNEL);
>> +	if (xprt == NULL)
>> +		goto out;
>> +
>> +	xprt->max_reqs = max_req;
>> +	xprt->slot = kcalloc(max_req, sizeof(struct rpc_rqst), GFP_KERNEL);
>> +	if (xprt->slot == NULL)
>> +		goto out_free;
>> +
>> +	return xprt;
>> +
>> +out_free:
>> +	kfree(xprt);
>> +out:
>> +	return NULL;
>> +}
>> +EXPORT_SYMBOL_GPL(xprt_alloc);
> 
> If xprt_alloc is a generic function, used by different transport capabilities, 
> then it belongs in net/sunrpc/xprt.c, not in a transport-specific source file
> like xprtsock.c .

Will do.

> Also, would it makes sense to allocate these via a single kcalloc request, or
>  would that possibly result in a high-order (ie non-zero) allocation in some cases?

The kcalloc is used to allocate n elements of an equal size, but the first
element in this hypothetical allocation will be of another size...

  reply	other threads:[~2010-09-28 16:51 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-28 15:14 [PATCH v2 0/7] sunrpc: Preparations to create sockets in namespaces Pavel Emelyanov
2010-09-28 15:15 ` [PATCH 1/7] sunrpc: Factor out rpc_xprt allocation Pavel Emelyanov
2010-09-28 15:34   ` Chuck Lever
2010-09-28 16:51     ` Pavel Emelyanov [this message]
2010-09-28 17:02       ` Chuck Lever
2010-09-28 15:15 ` [PATCH 2/7] sunrpc: Factor out rpc_xprt freeing Pavel Emelyanov
2010-09-28 15:37   ` Chuck Lever
2010-09-28 15:16 ` [PATCH 3/7] sunrpc: Add net argument to svc_create_xprt Pavel Emelyanov
2010-09-28 15:16 ` [PATCH 4/7] sunrpc: Pull net argument downto svc_create_socket Pavel Emelyanov
2010-09-28 15:17 ` [PATCH 5/7] sunrpc: Add net to rpc_create_args Pavel Emelyanov
2010-09-28 15:17 ` [PATCH 6/7] sunrpc: Add net to xprt_create Pavel Emelyanov
2010-09-28 15:18 ` [PATCH 7/7] sunrpc: Tag rpc_xprt with net Pavel Emelyanov

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=4CA21D07.4070900@parallels.com \
    --to=xemul@parallels.com \
    --cc=Trond.Myklebust@netapp.com \
    --cc=bfields@fieldses.org \
    --cc=chuck.lever@oracle.com \
    --cc=linux-nfs@vger.kernel.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.