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]
Message-ID: <BYAPR11MB3095CCF0E4931A4DB75AB3F7D9919@BYAPR11MB3095.namprd11.prod.outlook.com>
Date:   Wed, 10 Mar 2021 02:45:10 +0000
From:   "Chen, Mike Ximing" <mike.ximing.chen@...el.com>
To:     Greg KH <gregkh@...uxfoundation.org>
CC:     "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>,
        "Williams, Dan J" <dan.j.williams@...el.com>,
        "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



> -----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?

Thanks
Mike

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ