[dpdk-dev] [PATCH v2 01/13] net/mlx5: add representor recognition on kernels 5.x
Slava Ovsiienko
viacheslavo at mellanox.com
Tue Mar 26 08:33:19 CET 2019
> -----Original Message-----
> From: Stephen Hemminger <stephen at networkplumber.org>
> Sent: Monday, March 25, 2019 20:08
> To: Slava Ovsiienko <viacheslavo at mellanox.com>
> Cc: dev at dpdk.org; Shahaf Shuler <shahafs at mellanox.com>
> Subject: Re: [dpdk-dev] [PATCH v2 01/13] net/mlx5: add representor
> recognition on kernels 5.x
>
> On Mon, 25 Mar 2019 17:03:22 +0000
> Viacheslav Ovsiienko <viacheslavo at mellanox.com> wrote:
>
> > + if (switch_id_set) {
> > + if (info.port_name_new) {
> > + /* New representors naming schema. */
> > + if (port_name_set) {
> > + info.master = (info.port_name == -1);
> > + info.representor = (info.port_name != -1);
> > + }
> > + } else {
> > + /* Legacy representors naming schema. */
> > + info.master = (!port_name_set || num_vf_set);
> > + info.representor = port_name_set && !num_vf_set;
> > + }
> > + }
> > + assert(!(data.master && data.representor));
> > memcpy(arg, &info, sizeof(info));
> > return 0;
>
> Since assert() is often removed in non-debug envirionments,
Assert should be removed (compiled out) in non-debug environments. If not (suddenly) - it must be resolved.
> why not add a log message and return an error instead?
Because there is no code producing assert wrong condition. No valid combination of entry values to produce master&&representor. It is intended by design. We do not expect master&&representor condition at all. It should never happen. Otherwise, we should notify the developer (because design is corrupted somewhere - and definitely it is not a runtime/user problem). So, assert seems to be the most relevant entity here.
>>instead?
We could add error/log in parallel, not instead of.
With best regards,
Slava
More information about the dev
mailing list