[dpdk-dev] [PATCH 00/56] Solarflare libefx-based PMD

Ferruh Yigit ferruh.yigit at intel.com
Fri Nov 25 11:25:25 CET 2016


On 11/24/2016 4:15 PM, Andrew Rybchenko wrote:
> On 11/23/2016 06:29 PM, Ferruh Yigit wrote:
>> On 11/21/2016 3:00 PM, Andrew Rybchenko wrote:
>>> The patch series adds Solarflare libefx-based network PMD.
>>>
>>> This version of the driver supports Solarflare SFN7xxx and SFN8xxx
>>> families of 10/40 Gbps adapters.
>>>
>>> libefx is a platform-independent library to implement drivers for
>>> Solarflare network adapters. It provides unified adapter family
>>> independent interface (if possible). FreeBSD [1] and illumos [2]
>>> drivers are built on top of the library.
>>>
>>> The patch series could be logically structured into 5 sub-series:
>>>  1. (1) add the driver skeleton including documentation
>>>  2. (2-30) import libefx and include it in build with the latest patch
>>>  3. (31-43) implement minimal device level operations in steps
>>>  4. (44-51) implement Rx subsystem
>>>  5. (52-56) implement Tx subsystem
>>>
>>> Functional driver with multi-queue support capable to send and receive
>>> traffic appears with the last patch in the series.
>>>
>>> The following design decisions are made during development:
>>>
>>>  1. Since libefx uses positive errno return codes, positive errno
>>>     return codes are used inside the driver and coversion to negative
>>>     is done on return from eth_dev_ops callbacks. We think that it
>>>     is the less error-prone way.
>>>
>>>  2. Another Solarflare PMD with in-kernel part (for control operations)
>>>     is considered and could be added in the future. Code for data path
>>>     should be shared by these two drivers. libefx-based PMD is put into
>>>     'efx' subdirectory to have a space for another PMD and shared code.
>>>
>>>  3. Own event queue (a way to deliver events from HW to host CPU) is
>>>     used for house-keeping (e.g. link status notifications), each Tx
>>>     and each Rx queue. No locks on datapath are requires in this case.
>>>
>>>  4. Alarm is used to periodically poll house-keeping event queue.
>>>     The event queue is used to deliver link status change notifications,
>>>     Rx/Tx queue flush events, SRAM events. It is not used on datapath.
>>>     The event queue polling is protected using spin-lock since
>>>     concurrent access from different contexts is possible (e.g. device
>>>     stop when polling alarm is running).
>>>
>>> [1] https://svnweb.freebsd.org/base/head/sys/dev/sfxge/common/
>>> [2] https://github.com/illumos/illumos-gate/tree/master/usr/src/uts/common/io/sfxge/common/
>>>
>>> ---
>> I would like to note that very well organized patchset. Thank you for
>> your effort.
> 
> Thanks a lot, it is very pleasant to read it.
> 
> Please, see my questions in thread for patches 01/56 (about compiler
> versions to test on) and 30/56 (about libefx configuration documentation).
> 
> Also I'd like to ask a question about the further patches submission.
> We have about 40 patches which support various features (RSS, stats,
> flow control and many others). What is the preferred way to submit it?
> A. Separately since they are not so tightly related (but in fact cannot be
> applied in random order since some touch the same lines in code)
> B. As a series to process everything in one go.

If they can't be applied in random order, it is better send as a patchset.

But if you can make multiple logically independent patchsets with small
effort, please do, smaller patchsets are easier to chew.

> 
> Thanks,
> Andrew.



More information about the dev mailing list