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.
