From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by gabe.freedesktop.org (Postfix) with ESMTPS id C24C910E3C8 for ; Tue, 8 Nov 2022 09:39:38 +0000 (UTC) Date: Tue, 8 Nov 2022 11:39:43 +0200 From: Petri Latvala To: Kamil Konieczny , igt-dev@lists.freedesktop.org, Arkadiusz Hiler Message-ID: References: <20221107120151.2365523-1-petri.latvala@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [igt-dev] [PATCH i-g-t 1/6] runner: Use a bigger buffer for receiving test outputs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: igt-dev-bounces@lists.freedesktop.org Sender: "igt-dev" List-ID: On Mon, Nov 07, 2022 at 05:45:26PM +0100, Kamil Konieczny wrote: > Hi Petri, > > On 2022-11-07 at 14:01:46 +0200, Petri Latvala wrote: > > Stream-based receiving was able to use buffers of any size for read(), > > but with datagrams we actually need to prepare for actual sizes. In > > practice, some file dumps from tests come as single log packets of a > > couple of kB. > > > > Signed-off-by: Petri Latvala > > Cc: Arkadiusz Hiler > > Cc: Kamil Konieczny > > --- > > runner/executor.c | 14 ++++++++++---- > > 1 file changed, 10 insertions(+), 4 deletions(-) > > > > diff --git a/runner/executor.c b/runner/executor.c > > index a79a34e0..1fcc9afe 100644 > > --- a/runner/executor.c > > +++ b/runner/executor.c > > @@ -857,7 +857,8 @@ static int monitor_output(pid_t child, > > char **abortreason) > > { > > fd_set set; > > - char buf[2048]; > > + char *buf; > > + size_t bufsize; > > char *outbuf = NULL; > > size_t outbufsize = 0; > > char current_subtest[256] = {}; > > @@ -910,6 +911,9 @@ static int monitor_output(pid_t child, > > } > > } > > > > + bufsize = 262144; /* 256 kiB */ > > imho it is better to use define and also write this as 256*1024 > and put it in header. Sure. > If you increase this size maybe you can drop splitting ? Splitting is only done for log packets. Currently there's no obvious way for other packet types to be larger than reasonable but for futureproofing it's good to be defensive in both ends. Having e.g. assertion failure reason fields (when that is stuffed into the subtest result packet) go multiple kilobytes sounds wild but who knows what kind of autogenerated igt_assert macros people will attempt to write... -- Petri Latvala