On Wed, Mar 2, 2016 at 4:29 PM, Thomas Monjalon <thomas.monjalon at 6wind.com> wrote:
> > Should I split additional definitions/documentation that's not currently > > used in the driver as well? Or should it stay as only enough to document > > what the driver already does? > > I don't understand the question. > If something is not used, it should not been there. > Basically, since the header is the only current public documentation on the hardware, if someone without access to the whole header was interested in adding features to the driver, they wouldn't have the documentation to allow them to do so. I understand that a header file in DPDK is not the right way for Broadcom to release documentation on their hardware and firmware, but I was thinking it would be better than nothing. Further, as mentioned in another email, this header file is mechanically derived from one that is planned to be released separately, so it would be a slightly lower support burden to use the mechanically derived one rather than manually importing changes. No problems slimming it down though. > > It's a fairly work-intensive project to deconstruct the existing driver > > into a series of small patches that work at each step, is this a hard > > requirement? (if so, I'd better get cracking) > > There is no hard requirement. I'm just giving you some advices to get > some reviewers and make them confident when accepting your patches. > By the way, you would get more attention by introducing the device with > some web links and performance numbers in the cover letter. > It is also appreciated to provide a documentation in doc/guides/nics/. > You could also fill the (new) table in overview.rst. > Thanks for the pointers, I'll try to get as many of the suggestions done as possible and talk to marketing to find web resources for the device and its performance. -- Stephen Hurd Principal Engineer - Software Development Broadcom Corporation 949-926-8039 stephen.hurd at broadcom.com
