linux-kernel - RE: [PATCH v10 01/20] dlb: add skeleton for DLB driver

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-next>] [day] [month] [year] [list]

Message-ID: <BYAPR11MB309511566DBD522FE70D971FD9859@BYAPR11MB3095.namprd11.prod.outlook.com>
Date:   Thu, 18 Feb 2021 07:34:31 +0000
From:   "Chen, Mike Ximing" <mike.ximing.chen@...el.com>
To:     "Chen, Mike Ximing" <mike.ximing.chen@...el.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
CC:     "davem@...emloft.net" <davem@...emloft.net>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "arnd@...db.de" <arnd@...db.de>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "Williams, Dan J" <dan.j.williams@...el.com>,
        "pierre-louis.bossart@...ux.intel.com" 
        <pierre-louis.bossart@...ux.intel.com>
Subject: RE: [PATCH v10 01/20] dlb: add skeleton for DLB driver



> -----Original Message-----
> From: Mike Ximing Chen <mike.ximing.chen@...el.com>
> Sent: Wednesday, February 10, 2021 12:54 PM
> To: netdev@...r.kernel.org
> Cc: davem@...emloft.net; kuba@...nel.org; arnd@...db.de;
> gregkh@...uxfoundation.org; Williams, Dan J <dan.j.williams@...el.com>; pierre-
> louis.bossart@...ux.intel.com; Gage Eads <gage.eads@...el.com>
> Subject: [PATCH v10 01/20] dlb: add skeleton for DLB driver
> 
> diff --git a/Documentation/misc-devices/dlb.rst b/Documentation/misc-
> devices/dlb.rst
> new file mode 100644
> index 000000000000..aa79be07ee49
> --- /dev/null
> +++ b/Documentation/misc-devices/dlb.rst
> @@ -0,0 +1,259 @@
> +.. SPDX-License-Identifier: GPL-2.0-only
> +
> +===========================================
> +Intel(R) Dynamic Load Balancer Overview
> +===========================================
> +
> +:Authors: Gage Eads and Mike Ximing Chen
> +
> +Contents
> +========
> +
> +- Introduction
> +- Scheduling
> +- Queue Entry
> +- Port
> +- Queue
> +- Credits
> +- Scheduling Domain
> +- Interrupts
> +- Power Management
> +- User Interface
> +- Reset
> +
> +Introduction
> +============
> +
> +The Intel(r) Dynamic Load Balancer (Intel(r) DLB) is a PCIe device that
> +provides load-balanced, prioritized scheduling of core-to-core communication.
> +
> +Intel DLB is an accelerator for the event-driven programming model of
> +DPDK's Event Device Library[2]. The library is used in packet processing
> +pipelines that arrange for multi-core scalability, dynamic load-balancing, and
> +variety of packet distribution and synchronization schemes.
> +
> +Intel DLB device consists of queues and arbiters that connect producer
> +cores and consumer cores. The device implements load-balanced queueing
> features
> +including:
> +- Lock-free multi-producer/multi-consumer operation.
> +- Multiple priority levels for varying traffic types.
> +- 'Direct' traffic (i.e. multi-producer/single-consumer)
> +- Simple unordered load-balanced distribution.
> +- Atomic lock free load balancing across multiple consumers.
> +- Queue element reordering feature allowing ordered load-balanced distribution.
> +

Hi Jakub/Dave,
This is a device driver for a HW core-to-core communication accelerator. It is submitted 
to "linux-kernel" for a module under device/misc. Greg suggested (see below) that we
also sent it to you for any potential feedback in case there is any interaction with
networking initiatives. The device is used to handle the load balancing among CPU cores
after the packets are received and forwarded to CPU. We don't think it interferes
with networking operations, but would appreciate very much your review/comment on this.
 
Thanks for your help.
Mike

> As this is a networking related thing, I would like you to get the
>proper reviews/acks from the networking maintainers before I can take
>this.
>
>Or, if they think it has nothing to do with networking, that's fine too,
>but please do not try to route around them.
>
>thanks,
>
>greg k-h