Hi

On 2017-01-02, Philip Prindeville wrote:
> > On Jan 2, 2017, at 10:01 AM, Jo-Philipp Wich <j...@mein.io> wrote:
> > 
> > Hi,
> >   
> >> The x86/64/config-default is missing the following switches:
> >> 
> >> CONFIG_MCORE2=y  
[...]
> Right, this is why I’m trying to create a new target (or subtarget) called 
> “xeon” which is optimized for Xeon targets and leverages the on-chip 
> crypto-accelerators.

This is just an optimization, but not actually needed to get the
firmware running on your target CPU. While it may, or may not, provide
measurable speedups, none of the large(r) binary distros consider this
to be a necessary optimization, so why do you think it's necessary to
provide just this tiny micro-optimization as a dedicated subtarget with
all the overhead this entails - rather than just using as a local 
configuration for your own builds?

> We’ve come a long way since the Athalon-64 (k8) in 2004.

The situation on amd64/ x86_64 is quite a bit better than on i[3456]86,
probably very little actually makes a difference for routing tasks
(this could be different if LEDE would be a common basis for image
or video transcoding, but I seriously doubt that optimizing for core2
would actually make a significant difference on a router, especially
considering that pretty much any amd64/ x86_64 CPU[1] is way more 
powerful than any of the more prevalent routing architectures). I think 
it would be useful to actually show the difference your change makes on 
modern CPUs, before proactively introducing new subtargets for cosmetic 
reasons.

Regards
        Stefan Lippers-Hollmann

[1]     I'm quite convinced that even a 2003 vintage AMD64 Opteron from
        the first generation sledgehammer design wouldn't find its 
        limitations on the CPU side (unless you go beyond 1 GBit/s), but
        rather on the bus connection of your ethernet cards (old PCI 
        won't saturate a 1 GBit/s link).

Attachment: pgpYYJ3vuiMmP.pgp
Description: Digitale Signatur von OpenPGP

_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Reply via email to