From:   "Chen, Mike Ximing" <mike.ximing.chen@intel.com>
To:     Andrew Lunn <andrew@lunn.ch>
CC:     "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "arnd@arndb.de" <arnd@arndb.de>,
        "gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
        "Williams, Dan J" <dan.j.williams@intel.com>,
        "pierre-louis.bossart@linux.intel.com" 
        <pierre-louis.bossart@linux.intel.com>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "davem@davemloft.net" <davem@davemloft.net>,
        "kuba@kernel.org" <kuba@kernel.org>
Subject: RE: [RFC PATCH v12 00/17] dlb: introduce DLB device driver
Thread-Topic: [RFC PATCH v12 00/17] dlb: introduce DLB device driver
Thread-Index: AQHX9jcJdm85rPhvxUq3c7I9WRTitKw8sTaAgAE5rGA=
Date:   Wed, 22 Dec 2021 04:37:29 +0000
Message-ID: <CO1PR11MB51708FDE2087EE1F382AD14CD97D9@CO1PR11MB5170.namprd11.prod.outlook.com>
References: <20211221065047.290182-1-mike.ximing.chen@intel.com>
 <YcGhG8bdUi4WyXAf@lunn.ch>
In-Reply-To: <YcGhG8bdUi4WyXAf@lunn.ch>
Accept-Language: en-US
Content-Language: en-US
dlp-version: 11.6.200.16
dlp-reaction: no-action
dlp-product: dlpe-windows
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?XObPFMBCypTC7G/A2i4Be5Nzv1jl5hEUTohO2zFk6EiV5fobcO3xwLh+hpg9?=
 =?us-ascii?Q?QcNEp/JxejSYcNbbBEgwuUueoMz5s+Mai+Q//EL3rWkT/wirVW363hG35bHZ?=
 =?us-ascii?Q?qXtCZfghx+JOO4cBfewjNytsJE3OCSA1eIpe4jmNeAQPnhi4Nn3titslT6cR?=
 =?us-ascii?Q?+q2zTgHA7/0yN826U2sbphqq3KumVVq0QdS5yX6QI+Cw/ki7KHlZiA0bv64c?=
 =?us-ascii?Q?uVWJbzBpPsS0q6CAXfuFRFTmUiGz/HTrhXHshtFDjf3TGrIKaNr5WAWnw99R?=
 =?us-ascii?Q?Jz/QcxiUCzQYKKgcwfEp9h1/P01ogC+Ux0jacpUyi/abjKdsdhIf3umf+RGV?=
 =?us-ascii?Q?fqI1dCVVxYKrlTbKiKScDsxMqjgW9Zr0xLqUdFfTtA7VrgGYAlkAW3b+Pf1A?=
 =?us-ascii?Q?DN7yLFhQHQFdoJR+TnrYR0kucnLrY17vjlar7qT3MixNMKy+uFLn4uksd6l5?=
 =?us-ascii?Q?fJSfJr1GjEsTLPDwYY0QIY/ljn3FLzUDKY4BNPDGF94w32y4/rKzEJdVjMVL?=
 =?us-ascii?Q?gXAafG2F7hq+7x7tJdoeNRmZQ1RomsTdBPsHseLhaLxqPBaYLzZPCHzG4I0X?=
 =?us-ascii?Q?oNGfHzscQ8Uu1lH2DqeenTZB0asPjVuKk0JVXbwHfnZ2e3Ez0rYT9w+a54a2?=
 =?us-ascii?Q?e2B2+P29xHeAWGkfiJQQAzQntpQD4mMoZiIhOVeIMLRbTL3pML+XA/uyRviY?=
 =?us-ascii?Q?2hjWvZb3j7hNTW394dywPddwn4EnXnXOqfpFyR3CGYcDtOMO81WU7poK0o4w?=
 =?us-ascii?Q?T6QXGJ024yPKLzGkrEsyIzXRfRVnPJ9EbEPSf/CnYmXjyirGlfSu1J7aLSMC?=
 =?us-ascii?Q?5Op8LRwrgx2CvoSrGF4fiMy4ZGLElJYL+ryP61PRicAcVBjqKZb+C8tdJ+1v?=
 =?us-ascii?Q?1IXUTJIBZiYAjqNSWSp0lD9UF9df7Zhi9vjAKmzylUN9wwxKAHfwkFXyilmq?=
 =?us-ascii?Q?MHCWj1EY/C40Nzm/YfFF98YyrSg2cUPAmrs9NqSbKFd6MlWN5Zab5L1u20RM?=
 =?us-ascii?Q?84JKYwDx/I1h7asneFYiYWlJlazsbSe6d7stULmHK0qaRq0RtpJK/Maido9K?=
 =?us-ascii?Q?7X2JpjZCLt0XvQ4Kp3IFb7ECVXukyUxiZAoQCoQWp7JJlHAXlS5DZlHHGDJQ?=
 =?us-ascii?Q?0nMyTWIRWw1h2jpqSCP7hOprqglszx6XCZpDVHd0ueE7LByFZ/mIUpVtm6+E?=
 =?us-ascii?Q?mesc3e0cBi8i7WsoRpfqP/pwjUy978ph0LYyL/Zxjn2ohyqdW92iFP4APgW6?=
 =?us-ascii?Q?quWXf6O754YjRJyDJRc0Rc8qrBrWfezs3CKiDlyB8pNNBeI0b2Db3GB7P4ff?=
 =?us-ascii?Q?jDUwcI3QjHHOS6SXgCHw1myA6PJbjd+msYwI2zQgUbNLO49ditUVjUZsAk7x?=
 =?us-ascii?Q?eNu8Zgy6XaNzIuA4JAx9gMQzw+EznrgP1Sc1gws9MEjHGs7k85DFi671eCRd?=
 =?us-ascii?Q?FjmgW7al/B+BhxhGA0Q2mLw8NWDhsGS+vzUJVbM5xWGkOzsI8PCp2Tw3PO0J?=
 =?us-ascii?Q?H5pWPHAj8H86MYC5IZ+NVegQ9KhZuayKblyqGkMIV/PTfH7rYEVQJFLKdkCW?=
 =?us-ascii?Q?8X+jFj1PKEWeAWkIymJ3i33ofkQDIS5VQqzgbwmUldN+deqaD11dLuY4KVr+?=
 =?us-ascii?Q?Gv9r4xjudxPSAJzR/+qRO7PXl1FdkorUJQulFy1wTqAhljPj9DzqZmB1L6j8?=
 =?us-ascii?Q?Pu+mSA=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB5170.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5b3096b4-7828-490f-dc2f-08d9c504c33c
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Dec 2021 04:37:29.4776
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 63DmYwf7HdRhDnhyL0egs4B+vZ/xnsr78F0HBMsRz9rBir7php1hiDm/TXhZG9Sg1P4SGw+JrbRfLtiWVvep3cyCYcOkFRwV/Uuxe2FoUv4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1440
X-OriginatorOrg: intel.com
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


> -----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.o=
rg; 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
>=20
> > 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.
>=20
> How about throw away configfs and use netlink? Messages are atomic, and y=
ou 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.
>=20
Hi Andrew,
As I explained in my other response, DLB is not a network accelerator and D=
LB
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 implementation=
s.

Thanks for the suggestion
Mike