Messages in this thread | | | From | "Chen, Mike Ximing" <> | Subject | RE: [RFC PATCH v12 00/17] dlb: introduce DLB device driver | Date | Wed, 22 Dec 2021 04:37:29 +0000 |
| |
> -----Original Message----- > From: Andrew Lunn <andrew@lunn.ch> > Sent: Tuesday, December 21, 2021 4:41 AM > To: Chen, Mike Ximing <mike.ximing.chen@intel.com> > Cc: linux-kernel@vger.kernel.org; arnd@arndb.de; gregkh@linuxfoundation.org; Williams, Dan J > <dan.j.williams@intel.com>; pierre-louis.bossart@linux.intel.com; netdev@vger.kernel.org; > davem@davemloft.net; kuba@kernel.org > Subject: Re: [RFC PATCH v12 00/17] dlb: introduce DLB device driver > > > 1. Before a scheduling domain is created/enabled, a set of parameters > > are passed to the kernel driver via configfs attribute files in an > > configfs domain directory (say $domain) created by user. Each > > attribute file corresponds to a configuration parameter of the domain. > > After writing to all the attribute files, user writes 1 to "create" > > attribute, which triggers an action (i.e., domain creation) in the > > kernel driver. Since multiple processes/users can access the $domain > > directory, multiple users can write to the attribute files at the same > > time. How do we guarantee an atomic update/configuration of a domain? > > In other words, if user A wants to set attributes 1 and 2, how can we > > prevent user B from changing attribute 1 and 2 before user A writes 1 > > to "create"? A configfs directory with individual attribute files > > seems to not be able to provide atomic configuration in this case. One > > option to solve this issue could be write a structured data (with a > > set of parameters) to a single attribute file. This would guarantee the atomic configuration, but may not > be a conventional configfs operation. > > How about throw away configfs and use netlink? Messages are atomic, and you can add an arbitrary > number of attributes to a single netlink message. It will also make your code more network like, since > nothing else in the network stack uses configfs, as far as i know. > Hi Andrew, As I explained in my other response, DLB is not a network accelerator and DLB driver is not a part of network stack. We would obviously prefer to resolve the atomic update and resource reset at tear-down Issues within the configfs framework if possible. But I will take a look at the netlink implementations.
Thanks for the suggestion Mike
| |