Re: ixg(4) performances

[David Young <dyoung%pobox.com@localhost>]

On Tue, Aug 26, 2014 at 10:25:52AM -0400, Christos Zoulas wrote:
> On Aug 26,  2:23pm, manu%netbsd.org@localhost (Emmanuel Dreyfus) wrote:
> -- Subject: Re: ixg(4) performances
> 
> | On Tue, Aug 26, 2014 at 12:57:37PM +0000, Christos Zoulas wrote:
> | > 
> ftp://ftp.supermicro.com/CDR-C2_1.20_for_Intel_C2_platform/Intel/LAN/v15.5/PROXGB/DOCS/SERVER/prform10.htm#Setting_MMRBC
> | 
> | Right, but NetBSD has no tool like Linux's setpci to tweak MMRBC, and if
> | the BIOS has no setting for it, NetBSD is screwed.
> | 
> | I see <dev/pci/pciio.h>  has a PCI_IOC_CFGREAD / PCI_IOC_CFGWRITE ioctl,
> | does that means Linux's setpci can be easily reproduced?
> 
> I would probably extend pcictl with cfgread and cfgwrite commands.

Emmanuel,

Most (all?) configuration registers are read/write.  Have you read the
MMRBC and found that it's improperly configured?

Are you sure that you don't have to program the MMRBC at every bus
bridge between the NIC and RAM?  I'm not too familiar with PCI Express,
so I really don't know.

Have you verified the information at
http://dak1n1.com/blog/7-performance-tuning-intel-10gbe with the 82599
manual?  I have tried to corroborate the information both with my PCI
Express book and with the 82599 manual, but I cannot make a match.
PCI-X != PCI Express; maybe ixgb != ixgbe?  (It sure looks like they're
writing about an 82599, but maybe they don't know what they're writing
about!)


Finally, adding cfgread/cfgwrite commands to pcictl seems like a step in
the wrong direction.  I know that this is UNIX and we're duty-bound to
give everyone enough rope, but may we reconsider our assisted-suicide
policy just this one time? :-)

How well has blindly poking configuration registers worked for us in
the past?  I can think of a couple of instances where an knowledgeable
developer thought that they were writing a helpful value to a useful
register and getting a desirable result, but in the end it turned out to
be a no-op.  In one case, it was an Atheros WLAN adapter where somebody
added to Linux some code that wrote to a mysterious PCI configuration
register, and then some of the *BSDs copied it.  In the other case, I
think that somebody used pci_conf_write() to write a magic value to a
USB host controller register that wasn't on a 32-bit boundary.  ISTR
that some incorrect value was written, instead.

Dave

-- 
David Young
dyoung%pobox.com@localhost    Urbana, IL    (217) 721-9981