patches for DPDK stable branches
 help / color / mirror / Atom feed
From: Shally Verma <shallyv@marvell.com>
To: "Jozwiak, TomaszX" <tomaszx.jozwiak@intel.com>,
	"Trahe, Fiona" <fiona.trahe@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>,
	"stable@dpdk.org" <stable@dpdk.org>
Cc: "Trybula, ArturX" <arturx.trybula@intel.com>
Subject: Re: [dpdk-stable] [PATCH] app/test-compress-perf: fix reliance on integer endianness
Date: Tue, 21 May 2019 08:03:42 +0000	[thread overview]
Message-ID: <CY4PR1801MB2053D55DC988E98534FFD143AD070@CY4PR1801MB2053.namprd18.prod.outlook.com> (raw)
In-Reply-To: <CA70B6012E3ADB4184D44E025E5FF01B6AC6ECBE@HASMSX114.ger.corp.intel.com>

HI Tomasz

> -----Original Message-----
> From: Jozwiak, TomaszX <tomaszx.jozwiak@intel.com>
> Sent: Tuesday, May 21, 2019 12:18 PM
> To: Trahe, Fiona <fiona.trahe@intel.com>; dev@dpdk.org; Shally Verma
> <shallyv@marvell.com>; stable@dpdk.org
> Cc: Trybula, ArturX <arturx.trybula@intel.com>
> Subject: [EXT] RE: [PATCH] app/test-compress-perf: fix reliance on integer
> endianness
> 
> External Email
> 
> ----------------------------------------------------------------------
> Hi Fiona,
> 
> Outlook issue :D  , so once again
> 
> > -----Original Message-----
> > From: Trahe, Fiona
> > Sent: Monday, May 20, 2019 4:06 PM
> > To: Jozwiak, TomaszX <tomaszx.jozwiak@intel.com>; dev@dpdk.org;
> > shallyv@marvell.com; stable@dpdk.org
> > Cc: Trahe, Fiona <fiona.trahe@intel.com>; Trybula, ArturX
> > <arturx.trybula@intel.com>
> > Subject: RE: [PATCH] app/test-compress-perf: fix reliance on integer
> > endianness
> >
> > HI Tomasz,
> >
> > > -----Original Message-----
> > > From: Jozwiak, TomaszX
> > > Sent: Monday, May 20, 2019 2:26 PM
> > > To: dev@dpdk.org; Trahe, Fiona <fiona.trahe@intel.com>; Jozwiak,
> > > TomaszX <tomaszx.jozwiak@intel.com>; shallyv@marvell.com;
> > > stable@dpdk.org
> > > Subject: [PATCH] app/test-compress-perf: fix reliance on integer
> > > endianness
> > >
> > > This patch fixes coverity issue:
> > > Reliance on integer endianness (INCOMPATIBLE_CAST) in
> > parse_window_sz
> > > function.
> > >
> > > Coverity issue: 328524
> > > Fixes: e0b6287c035d ("app/compress-perf: add parser")
> > > Cc: stable@dpdk.org
> > >
> > > Signed-off-by: Tomasz Jozwiak <tomaszx.jozwiak@intel.com>
> > > ---
> > >  app/test-compress-perf/comp_perf_options_parse.c | 4 +++-
> > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/app/test-compress-perf/comp_perf_options_parse.c
> > > b/app/test-compress- perf/comp_perf_options_parse.c index
> > > 2fb6fb4..56ca580 100644
> > > --- a/app/test-compress-perf/comp_perf_options_parse.c
> > > +++ b/app/test-compress-perf/comp_perf_options_parse.c
> > > @@ -364,13 +364,15 @@ parse_max_num_sgl_segs(struct
> > comp_test_data
> > > *test_data, const char *arg)  static int  parse_window_sz(struct
> > > comp_test_data *test_data, const char *arg)  {
> > > -	int ret = parse_uint16_t((uint16_t *)&test_data->window_sz, arg);
> > > +	uint16_t tmp;
> > > +	int ret = parse_uint16_t(&tmp, arg);
> > >
> > >  	if (ret) {
> > >  		RTE_LOG(ERR, USER1, "Failed to parse window size\n");
> > >  		return -1;
> > >  	}
> > >
> > > +	test_data->window_sz = (int)tmp;
> > >  	return 0;
> > >  }
> > [Fiona] I expect this fixes this coverity issue - but will it result in another one?
> > window_sz on the xform is uint8_t - so this int will get truncated
> > later, and there's no cast done at that point.
> > Would it be better to add a new parse_uint8_t fn and change test-data-
> > >window_sz to a unit8_t?
> > Or add that cast?
> [Tomek] I measn it's ok. There's a check inside comp_perf_check_capabilities
> function.
> If the value from test_data->window_sz > cap->window_size we have a fail.
> Also during parsing there's a check is value from command line between 0 and
> UINT16_MAX, so in my opinion all cases are tested. The point is there's only
> one place where we're parsing uint8_t value.  parse_uint8_t function will be
> especially for that.
[Shally] What is window_sz in test data ?is it base 2 log of (actual window length) or actual window length in bytes? lib spec mention this as struct rte_param_log2_range, so
If test window size is actual window length in bytes then I assume test perf should check for test_data->window_sz > 2 pow cap->window_size but that doesn't look like the case. 
So if it is log value, then coding wise typecasting here doesn't look right. Though it add need for extra function to parse_uint8, but that looks like cleaner approach to use.


  reply	other threads:[~2019-05-21  8:03 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-20 13:26 [dpdk-stable] [PATCH] app/test-compress-perf: fix improper use of negative value Tomasz Jozwiak
2019-05-20 13:26 ` [dpdk-stable] [PATCH] app/test-compress-perf: fix reliance on integer endianness Tomasz Jozwiak
2019-05-20 14:05   ` Trahe, Fiona
2019-05-20 14:25     ` Jozwiak, TomaszX
2019-05-21  6:47     ` Jozwiak, TomaszX
2019-05-21  8:03       ` Shally Verma [this message]
2019-05-21  8:47         ` Jozwiak, TomaszX
2019-05-29 13:46           ` Trahe, Fiona
2019-06-03 13:44             ` Shally Verma
2019-05-20 13:39 ` [dpdk-stable] [PATCH] app/test-compress-perf: fix improper use of negative value Trahe, Fiona
2019-06-19 14:55   ` Akhil Goyal

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=CY4PR1801MB2053D55DC988E98534FFD143AD070@CY4PR1801MB2053.namprd18.prod.outlook.com \
    --to=shallyv@marvell.com \
    --cc=arturx.trybula@intel.com \
    --cc=dev@dpdk.org \
    --cc=fiona.trahe@intel.com \
    --cc=stable@dpdk.org \
    --cc=tomaszx.jozwiak@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).