> On May 19, 2015, at 10:50 AM, Alexander Duyck <alexander.h.du...@redhat.com> > wrote: > > These two patches are very much related.
They are only related because I saw an opportunity to do this while working on the other issue. That is the only relationship. <snip material on the other patch> >>> Artificially limiting the size of the VPD does nothing but cut off possibly >>> useful data, you would be better of providing all of the data on only the >>> first function than providing only partial data on all functions and adding >>> extra lock overhead. >> This limit only limits the maximum that the OS will read to what is >> architecturally possible in these devices. Yes, PCIe architecturally >> provides for the possibility of more, but these devices do not. More >> repeating data can be read, however slowly, but there is no possibility of >> useful content beyond the first 1K. If this limit were set to 0x100, which >> is more in line what the actual usage is, it would be an artificial limit, >> but at 1K it is not. Oh and it does include devices made by others that >> incorporate Intel Ethernet silicon, not just Intel-built devices. > > As per section 3.4.4 of the X540 datasheet the upper addressable range for > the VPD section is 0xFFF which means the upper limit for the hardware is > 0x1000, not 0x400. Ok. I have no problem changing it to that. I had been looking at other specs, but 0x1000 really is a hard limit. <snip more material mostly relating to the other patch> -- Mark Rustad, Networking Division, Intel Corporation
signature.asc
Description: Message signed with OpenPGP using GPGMail
