netdev - RE: [RFC PATCH v12 01/17] 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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CO1PR11MB51705AE8B072576F31FEC18CD97C9@CO1PR11MB5170.namprd11.prod.outlook.com>
Date:   Tue, 21 Dec 2021 20:56:42 +0000
From:   "Chen, Mike Ximing" <mike.ximing.chen@...el.com>
To:     Andrew Lunn <andrew@...n.ch>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.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>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "kuba@...nel.org" <kuba@...nel.org>
Subject: RE: [RFC PATCH v12 01/17] dlb: add skeleton for DLB driver



> -----Original Message-----
> From: Andrew Lunn <andrew@...n.ch>
> Sent: Tuesday, December 21, 2021 4:54 AM
> To: Chen, Mike Ximing <mike.ximing.chen@...el.com>
> Cc: linux-kernel@...r.kernel.org; arnd@...db.de; gregkh@...uxfoundation.org; Williams, Dan J
> <dan.j.williams@...el.com>; pierre-louis.bossart@...ux.intel.com; netdev@...r.kernel.org;
> davem@...emloft.net; kuba@...nel.org
> Subject: Re: [RFC PATCH v12 01/17] dlb: add skeleton for DLB driver
> 
> > +The following diagram shows a typical packet processing pipeline with the Intel DLB.
> > +
> > +                              WC1              WC4
> > + +-----+   +----+   +---+  /      \  +---+  /      \  +---+   +----+   +-----+
> > + |NIC  |   |Rx  |   |DLB| /        \ |DLB| /        \ |DLB|   |Tx  |   |NIC  |
> > + |Ports|---|Core|---|   |-----WC2----|   |-----WC5----|   |---|Core|---|Ports|
> > + +-----+   -----+   +---+ \        / +---+ \        / +---+   +----+   ------+
> > +                           \      /         \      /
> > +                              WC3              WC6
> 
> This is the only mention of NIC here. Does the application interface to the network stack in the usual way
> to receive packets from the TCP/IP stack up into user space and then copy it back down into the MMIO
> block for it to enter the DLB for the first time? And at the end of the path, does the application copy it
> from the MMIO into a standard socket for TCP/IP processing to be send out the NIC?
> 
For load balancing and distribution purposes, we do not handle packets directly in DLB. Instead, we only
send QEs (queue events) to MMIO for DLB to process. In an network application, QEs (64 bytes each) can
contain pointers to the actual packets. The worker cores can use these pointers to process packets and
forward them to the next stage. At the end of the path, the last work core can send the packets out to NIC.
 
> Do you even needs NICs here? Could the data be coming of a video camera and you are distributing image
> processing over a number of cores?
No, the diagram is just an example for packet processing applications. The data can come from other sources
such video cameras. The DLB can schedule up to 100 million packets/events per seconds. The frame rate from
a single camera is normally much, much lower than that.

> 
> 	 Andrew