All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: Gris Ge <fge@redhat.com>
Cc: dm-devel@redhat.com
Subject: Re: [PATCH V3 1/3] multipath-tools: Increase MAX_REPLY_LEN.
Date: Mon, 4 Jul 2016 08:05:19 +0200	[thread overview]
Message-ID: <5779FC9F.6010209@suse.de> (raw)
In-Reply-To: <20160702002537.GA1361@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1535 bytes --]

On 07/02/2016 02:25 AM, Gris Ge wrote:
> On Fri, Jul 01, 2016 at 04:46:53PM +0200, Hannes Reinecke wrote:
>>> -#define MAX_REPLY_LEN		65536
>>> +#define MAX_REPLY_LEN		10485760
>>> +/* ^ 10 MiB, enough for 'show maps json' command with 10k paths which
>>> + *   requires about 8 MiB */
>>>  
>>>  
>> Huh.
>> Can't say I like it. The limit is pretty much self-imposed, so I'd
>> rather bite the bullet and make it size-independent.
>>
>> Cheers,
>>
>> Hannes
>> -- 
>> Dr. Hannes Reinecke		   Teamlead Storage & Networking
> 
> Hi Hannes Reinecke,
> 
> How about limit the input command string size and let multipathd
> output size-independent?
> 
Hmm?
We already know the size of the input (we're getting it from the
commandline, after all). So there's no need to arbitrary limit anything
here; we know exactly how much memory we need to allocate.
It's just for the _output_ where we need to be careful, as we need to
ensure that we don't allocate insane amount of memory in the daemon nor
in the client.
So for the output we should look at implementing some sort of chunked
response; maybe having a 4k transmit buffer, and adding a status bit
in the CLI response instructing the client to keep on reading.
Or something like that.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		   Teamlead Storage & Networking
hare@suse.de			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)

[-- Attachment #2: 0x4EC8A8CF.asc --]
[-- Type: application/pgp-keys, Size: 28668 bytes --]

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]



  reply	other threads:[~2016-07-04  6:05 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-28  3:52 [PATCH] Introducing multipath C API <libdmmp/libdmmp.h> Gris Ge
2016-01-28  9:15 ` Hannes Reinecke
2016-01-28  9:40   ` Gris Ge
2016-02-01 13:13   ` Todd Gill
2016-02-01 13:36     ` Hannes Reinecke
2016-02-12  8:10       ` [PATCH V2] Introducing multipath C API Gris Ge
2016-02-12  8:10         ` [PATCH V2] Introducing multipath C API <libdmmp/libdmmp.h> Gris Ge
2016-03-04 16:06           ` Benjamin Marzinski
2016-03-05  9:46             ` Gris Ge
2016-07-01 12:46           ` [PATCH V3 0/3] Introducing multipath C API Gris Ge
2016-07-01 12:46             ` [PATCH V3 1/3] multipath-tools: Increase MAX_REPLY_LEN Gris Ge
2016-07-01 14:46               ` Hannes Reinecke
2016-07-02  0:25                 ` Gris Ge
2016-07-04  6:05                   ` Hannes Reinecke [this message]
2016-07-04  9:11                     ` Gris Ge
2016-07-04  9:17                       ` [PATCH V4 0/3] Introducing multipath C API Gris Ge
2016-07-04  9:17                         ` [PATCH V4 1/3] multipath-tools: New way to limit the IPC command length Gris Ge
2016-07-04  9:17                         ` [PATCH V4 2/3] multipath-tools: Set errno mpath_recv_reply() when failure Gris Ge
2016-07-04  9:17                         ` [PATCH V4 3/3] multipath-tools: Introducing multipath C API Gris Ge
2016-07-04  9:27                         ` [PATCH V4 0/3] " Gris Ge
2016-07-04  9:29                         ` Please ignore this patch set. ([PATCH V4 0/3] Introducing multipath C API) Gris Ge
2016-07-04  9:40                         ` [PATCH V5 0/3] Introducing multipath C API Gris Ge
2016-07-04  9:40                           ` [PATCH V5 1/3] multipath-tools: New way to limit the IPC command length Gris Ge
2016-07-04  9:40                           ` [PATCH V5 2/3] multipath-tools: Set errno mpath_recv_reply() when failure Gris Ge
2016-07-04  9:40                           ` [PATCH V5 3/3] multipath-tools: Introducing multipath C API Gris Ge
2016-07-01 12:46             ` [PATCH V3 2/3] multipath-tools: Set errno mpath_recv_reply() when failure Gris Ge
2016-07-01 12:46             ` [PATCH V3 3/3] multipath-tools: Introducing multipath C API <libdmmp/libdmmp.h> Gris Ge
2016-07-01 12:55             ` [PATCH " Gris Ge
2016-07-01 13:06             ` [PATCH V3 " Gris Ge
2016-07-12  6:50 ` [PATCH V6 0/3] Introducing multipath C API Gris Ge
2016-07-12  6:50   ` [PATCH V6 1/3] multipath-tools: New way to limit the IPC command length Gris Ge
2016-07-15 21:35     ` Benjamin Marzinski
2016-07-18 12:38       ` Gris Ge
2016-08-12 15:57       ` Bart Van Assche
2016-08-12 21:35         ` Benjamin Marzinski
2016-08-12 21:49           ` Bart Van Assche
2016-07-12  6:50   ` [PATCH V6 2/3] multipath-tools: Set errno mpath_recv_reply() when failure Gris Ge
2016-07-12  6:50   ` [PATCH V6 3/3] multipath-tools: Introducing multipath C API Gris Ge
2016-07-15 21:36   ` [PATCH V6 0/3] " Benjamin Marzinski
2016-08-12 12:12 ` [PATCH V7 0/4] multipath: " Gris Ge
2016-08-12 12:12   ` [PATCH V7 1/4] libmpathcmd: Block SIGPIPE when write() Gris Ge
2016-08-12 16:01     ` Bart Van Assche
2016-08-12 12:12   ` [PATCH V7 2/4] multipath-tools: New way to limit the IPC command length Gris Ge
2016-08-12 15:48     ` Bart Van Assche
2016-08-12 21:53     ` Benjamin Marzinski
2016-08-12 12:12   ` [PATCH V7 3/4] multipath-tools: Set errno mpath_recv_reply() when failure Gris Ge
2016-08-12 12:12   ` [PATCH V7 4/4] multipath-tools: Introducing multipath C API Gris Ge
2017-02-24 12:50     ` [PATCH V5] " Gris Ge
2017-02-27  5:56       ` Christophe Varoqui
2017-02-24 13:07     ` Gris Ge
2016-08-12 13:26   ` [PATCH V7 0/4] multipath: " Gris Ge

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=5779FC9F.6010209@suse.de \
    --to=hare@suse.de \
    --cc=dm-devel@redhat.com \
    --cc=fge@redhat.com \
    /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.