> -----Original Message-----
> From: Stephen Hemminger <step...@networkplumber.org>
> Sent: Monday, March 25, 2019 20:08
> To: Slava Ovsiienko <viachesl...@mellanox.com>
> Cc: dev@dpdk.org; Shahaf Shuler <shah...@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 <viachesl...@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

Reply via email to