netdev - Re: [PATCH v10 14/20] dlb: add start domain ioctl

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 10 Mar 2021 12:19:23 -0800
From:   Dan Williams <dan.j.williams@...el.com>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     "Chen, Mike Ximing" <mike.ximing.chen@...el.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "arnd@...db.de" <arnd@...db.de>,
        "pierre-louis.bossart@...ux.intel.com" 
        <pierre-louis.bossart@...ux.intel.com>,
        "Brandeburg, Jesse" <jesse.brandeburg@...el.com>
Subject: Re: [PATCH v10 14/20] dlb: add start domain ioctl

On Wed, Mar 10, 2021 at 12:14 AM Greg KH <gregkh@...uxfoundation.org> wrote:
>
> On Wed, Mar 10, 2021 at 02:45:10AM +0000, Chen, Mike Ximing wrote:
> >
> >
> > > -----Original Message-----
> > > From: Greg KH <gregkh@...uxfoundation.org>
> > > On Wed, Feb 10, 2021 at 11:54:17AM -0600, Mike Ximing Chen wrote:
> > > >
> > > > diff --git a/drivers/misc/dlb/dlb_ioctl.c b/drivers/misc/dlb/dlb_ioctl.c
> > > > index 6a311b969643..9b05344f03c8 100644
> > > > --- a/drivers/misc/dlb/dlb_ioctl.c
> > > > +++ b/drivers/misc/dlb/dlb_ioctl.c
> > > > @@ -51,6 +51,7 @@
> > > DLB_DOMAIN_IOCTL_CALLBACK_TEMPLATE(create_ldb_queue)
> > > >  DLB_DOMAIN_IOCTL_CALLBACK_TEMPLATE(create_dir_queue)
> > > >  DLB_DOMAIN_IOCTL_CALLBACK_TEMPLATE(get_ldb_queue_depth)
> > > >  DLB_DOMAIN_IOCTL_CALLBACK_TEMPLATE(get_dir_queue_depth)
> > > > +DLB_DOMAIN_IOCTL_CALLBACK_TEMPLATE(start_domain)
> > > >
> > > > --- a/drivers/misc/dlb/dlb_pf_ops.c
> > > > +++ b/drivers/misc/dlb/dlb_pf_ops.c
> > > > @@ -160,6 +160,14 @@ dlb_pf_create_dir_port(struct dlb_hw *hw, u32 id,
> > > >                                  resp, false, 0);
> > > >  }
> > > >
> > > > +static int
> > > > +dlb_pf_start_domain(struct dlb_hw *hw, u32 id,
> > > > +             struct dlb_start_domain_args *args,
> > > > +             struct dlb_cmd_response *resp)
> > > > +{
> > > > + return dlb_hw_start_domain(hw, id, args, resp, false, 0);
> > > > +}
> > > > +
> > > >  static int dlb_pf_get_num_resources(struct dlb_hw *hw,
> > > >                               struct dlb_get_num_resources_args *args)
> > > >  {
> > > > @@ -232,6 +240,7 @@ struct dlb_device_ops dlb_pf_ops = {
> > > >   .create_dir_queue = dlb_pf_create_dir_queue,
> > > >   .create_ldb_port = dlb_pf_create_ldb_port,
> > > >   .create_dir_port = dlb_pf_create_dir_port,
> > > > + .start_domain = dlb_pf_start_domain,
> > >
> > > Why do you have a "callback" when you only ever call one function?  Why
> > > is that needed at all?
> > >
> > In our next submission, we are going to add virtual function (VF) support. The
> > callbacks for VFs are different from those for PF which is what we support in this
> > submission. We can defer the introduction of  the callback structure to when we
> > add the VF support. But since we have many callback functions, that approach
> > will generate many changes in then "existing" code. We thought that putting
> > the callback structure in place now would make the job of adding VF support easier.
> > Is it OK?
>
> No, do not add additional complexity when it is not needed.  It causes
> much more review work and I and no one else have any idea that
> "something might be coming in the future", so please do not make our
> lives harder.
>
> Make it simple, and work, now.  You can always add additional changes
> later, if it is ever needed.
>

Good points Greg, the internal reviews missed this, let me take
another once over before v11.