2016-12-01 13:16 GMT+01:00 Jisheng Zhang <jszh...@marvell.com>:
> On Thu, 1 Dec 2016 20:02:05 +0800 Jisheng Zhang wrote:
>> Hi Marcin,
>> On Thu, 1 Dec 2016 12:48:39 +0100 Marcin Wojtas wrote:
>> > Hi Jisheng,
>> > Which baseline do you use?
>> > It took me really lot of time to catch why RX broke after rebase from
>> > LKv4.1 to LKv4.4. Between those two, in commit:
>> > 97303480753e ("arm64: Increase the max granular size")
>> > L1_CACHE_BYTES for all ARMv8 platforms was increased to 128B and so
>> > did NET_SKB_PAD.
>> > And 128 is more than the maximum that can fit into packet offset
>> > [11:8]@0x1400. In such case this correction is needed. Did it answer
>> > your doubts?
>> That's key! Thanks a lot. In my repo, we don't have commit 97303480753e
>> ("arm64: Increase the max granular size")
>> I think it would be great if this information can be added into the commit
>> IIRC, arm64 maintainers considered to let L1_CACHE_BYTES the _minimum_ of
>> cache line sizes of arm64. If that's implemented and merged, then we can
> I just searched and found the email.
> "We may have to revisit this logic and consider L1_CACHE_BYTES the
> _minimum_ of cache line sizes in arm64 systems supported by the kernel.
> Do you have any benchmarks on Cavium boards that would show significant
> degradation with 64-byte L1_CACHE_BYTES vs 128?"
Thank you for the information. I debugged it before the discussion. In
future we would be able to revert it, however afair packet offset may
be needed by A3700 Buffer Management.