netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: "Chen, Mike Ximing" <mike.ximing.chen@intel.com>
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 01/17] dlb: add skeleton for DLB driver
Date: Tue, 21 Dec 2021 22:39:19 +0100	[thread overview]
Message-ID: <YcJJh9e2QCJOoEB/@lunn.ch> (raw)
In-Reply-To: <CO1PR11MB51705AE8B072576F31FEC18CD97C9@CO1PR11MB5170.namprd11.prod.outlook.com>

On Tue, Dec 21, 2021 at 08:56:42PM +0000, Chen, Mike Ximing wrote:
> 
> 
> > -----Original Message-----
> > From: Andrew Lunn <andrew@lunn.ch>
> > Sent: Tuesday, December 21, 2021 4:54 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 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.

Sorry for asking so many questions, but i'm trying to understand the
architecture. As a network maintainer, and somebody who reviews
network drivers, i was trying to be sure there is not an actual
network MAC and PHY driver hiding in this code.

So you talk about packets. Do you actually mean frames? As in Ethernet
frames? TCP/IP processing has not occurred? Or does this plug into the
network stack at some level? After TCP reassembly has occurred? Are
these pointers to skbufs?

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

So i'm trying to understand the scope of this accelerator. Is it just
a network accelerator? If so, are you pointing to skbufs? How are the
lifetimes of skbufs managed? How do you get skbufs out of the NIC? Are
you using XDP?

    Andrew

  reply	other threads:[~2021-12-21 21:39 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-21  6:50 [RFC PATCH v12 00/17] dlb: introduce DLB device driver Mike Ximing Chen
2021-12-21  6:50 ` [RFC PATCH v12 01/17] dlb: add skeleton for DLB driver Mike Ximing Chen
2021-12-21  7:00   ` Joe Perches
2021-12-21 23:22     ` Chen, Mike Ximing
2021-12-22  2:02       ` Joe Perches
2021-12-21  7:12   ` Greg KH
2021-12-21  8:57     ` Greg KH
2021-12-21 14:25       ` Chen, Mike Ximing
2021-12-21 14:42         ` Chen, Mike Ximing
2021-12-21 15:02           ` Greg KH
2021-12-21 14:05     ` Chen, Mike Ximing
2021-12-21  9:53   ` Andrew Lunn
2021-12-21 20:56     ` Chen, Mike Ximing
2021-12-21 21:39       ` Andrew Lunn [this message]
2021-12-21 23:05         ` Chen, Mike Ximing
2021-12-22 21:26           ` Andrew Lunn
2021-12-23  5:15             ` Chen, Mike Ximing
2021-12-23 10:22               ` Andrew Lunn
2021-12-27  0:40                 ` Chen, Mike Ximing
2021-12-21  6:50 ` [RFC PATCH v12 02/17] dlb: initialize DLB device Mike Ximing Chen
2021-12-21  6:50 ` [RFC PATCH v12 03/17] dlb: add resource and device initialization Mike Ximing Chen
2021-12-21  6:50 ` [RFC PATCH v12 04/17] dlb: add configfs interface and scheduling domain directory Mike Ximing Chen
2021-12-21  6:50 ` [RFC PATCH v12 05/17] dlb: add scheduling domain configuration Mike Ximing Chen
2021-12-21  6:50 ` [RFC PATCH v12 06/17] dlb: add domain software reset Mike Ximing Chen
2021-12-21  6:50 ` [RFC PATCH v12 07/17] dlb: add low-level register reset operations Mike Ximing Chen
2021-12-21  6:50 ` [RFC PATCH v12 08/17] dlb: add runtime power-management support Mike Ximing Chen
2021-12-21  6:50 ` [RFC PATCH v12 09/17] dlb: add queue create, reset, get-depth configfs interface Mike Ximing Chen
2021-12-21  6:50 ` [RFC PATCH v12 10/17] dlb: add register operations for queue management Mike Ximing Chen
2021-12-21  6:50 ` [RFC PATCH v12 11/17] dlb: add configfs interface to configure ports Mike Ximing Chen
2021-12-21  6:50 ` [RFC PATCH v12 12/17] dlb: add register operations for port management Mike Ximing Chen
2021-12-21  6:50 ` [RFC PATCH v12 13/17] dlb: add port mmap support Mike Ximing Chen
2021-12-21  6:50 ` [RFC PATCH v12 14/17] dlb: add start domain configfs attribute Mike Ximing Chen
2021-12-21  6:50 ` [RFC PATCH v12 15/17] dlb: add queue map, unmap, and pending unmap Mike Ximing Chen
2021-12-21  6:50 ` [RFC PATCH v12 16/17] dlb: add static queue map register operations Mike Ximing Chen
2021-12-21  6:50 ` [RFC PATCH v12 17/17] dlb: add basic sysfs interfaces Mike Ximing Chen
2021-12-21  7:20   ` Joe Perches
2021-12-21 23:18     ` Chen, Mike Ximing
2021-12-21  8:56   ` Greg KH
2021-12-21 14:07     ` Chen, Mike Ximing
2021-12-21 23:34   ` Stephen Hemminger
2021-12-22  4:21     ` Chen, Mike Ximing
2021-12-21  7:09 ` [RFC PATCH v12 00/17] dlb: introduce DLB device driver Greg KH
2021-12-21 14:03   ` Chen, Mike Ximing
2021-12-21 14:31     ` Greg KH
2021-12-21 18:44       ` Dan Williams
2021-12-21 19:57         ` Andrew Lunn
2021-12-22  8:01         ` Christoph Hellwig
2021-12-21  9:40 ` Andrew Lunn
2021-12-22  4:37   ` Chen, Mike Ximing

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YcJJh9e2QCJOoEB/@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=arnd@arndb.de \
    --cc=dan.j.williams@intel.com \
    --cc=davem@davemloft.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mike.ximing.chen@intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=pierre-louis.bossart@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).