Intel IXP4xx network drivers v.2 - Ethernet and HSS
Subsystems (2)
Quoted 5 lines · Michael Jones
Review
Quoted 3 lines
(quoted diff) +3
-0+#ifndef __ARMEB__ +#warning Little endian mode not supported +#endifPersonally I'm less fussed about WAN / LE support. Anyone with any sense will run ixp4xx boards doing such a specialised network operation as BE. Also, NSLU2-Linux can't test this functionality with our LE setup as we don't have this hardware on-board. You may just want to declare a depends on ARMEB in
Kconfig(with or without OR (ARM || BROKEN) ) and have done with it - it's up to you.
Christian Hohnstaedt's work did support LE though.
Not all ixp4xx boards are by definition "doing such a specialised network operation".
Krzysztof, why is LE not supported?
Do you need access to ixp4xx that starts in LE mode?
Signature · 2 lines
Tomasz Chmielewski http://wpkg.org
Quoted 13 lines · Tomasz Chmielewski
Quoted 10 lines · Michael Jones
Review
Quoted 3 lines
(quoted diff) +3
-0+#ifndef __ARMEB__ +#warning Little endian mode not supported +#endifPersonally I'm less fussed about WAN / LE support. Anyone with any sense will run ixp4xx boards doing such a specialised network operation as BE. Also, NSLU2-Linux can't test this functionality with our LE setup as we don't have this hardware on-board. You may just want to declare a depends on ARMEB in
Kconfig(with or without OR (ARM || BROKEN) ) and have done with it - it's up to you.
Quoted 5 lines
Christian Hohnstaedt's work did support LE though.
Not all ixp4xx boards are by definition "doing such a specialised network operation".
I was always curious, why do people want to run ixp4xx in LE mode? What are the benefits that overweight the obvious performance degradation?
Quoted 2 lines · Alexey Zaytsev
I was always curious, why do people want to run ixp4xx in LE mode? What are the benefits that overweight the obvious performance degradation?
Debian.
http://www.debian.org/ports/arm/
Michael-Luke
Why run ixp4xx LE? (Was: [PATCH] Intel IXP4xx network drivers v.2 - Ethernet and HSS)
Quoted 7 lines · Michael-Luke Jones
Quoted 2 lines · Alexey Zaytsev
I was always curious, why do people want to run ixp4xx in LE mode? What are the benefits that overweight the obvious performance degradation?
And also out-of-kernel drivers for things like webcams, which have been naively written for x86 little endian and have no concept of endian neutrality. In some cases it's just easier to run LE instead of fighting with the driver code.
BTW, for the consumer-level IXP42x devices (like the NSLU2) the performance difference is *completely* overwhelmed by slowness in the rest of the system.
-- Rod
Quoted 14 lines · Alexey Zaytsev
Quoted 13 lines · Tomasz Chmielewski
Quoted 10 lines · Michael Jones
Review
Quoted 3 lines
(quoted diff) +3
-0+#ifndef __ARMEB__ +#warning Little endian mode not supported +#endifPersonally I'm less fussed about WAN / LE support. Anyone with any sense will run ixp4xx boards doing such a specialised network operation as BE. Also, NSLU2-Linux can't test this functionality with our LE setup as we don't have this hardware on-board. You may just want to declare a depends on ARMEB in
Kconfig(with or without OR (ARM || BROKEN) ) and have done with it - it's up to you.
Quoted 8 lines
Quoted 5 lines
Christian Hohnstaedt's work did support LE though.
Not all ixp4xx boards are by definition "doing such a specialised network operation".
I was always curious, why do people want to run ixp4xx in LE mode? What are the benefits that overweight the obvious performance degradation?
I guess the main reason, at least for me, is that there is only one distro that properly supports LE ARM: Debian.
It greatly simplifies management/administration of a higher number of devices, given the fact that Debian also supports other architectures (not just x86/64, sometimes PPC, like most distros do).
Not always network performance is to most important factor.
Signature · 2 lines
Tomasz Chmielewski http://wpkg.org
Quoted 2 lines · Alexey Zaytsev
I was always curious, why do people want to run ixp4xx in LE mode? What are the benefits that overweight the obvious performance degradation?
Debian on the NSLU2 runs in LE, and it is pretty popular.
http://www.linuxdevices.com/news/NS3535328630.html
Gordon
Signature · 1 line
Gordon Farquharson
Quoted 2 lines · Alexey Zaytsev
I was always curious, why do people want to run ixp4xx in LE mode? What are the benefits that overweight the obvious performance degradation?
Debian is indeed a valid reason.
I wonder if it would be much work to create BE Debian as well. Simple automated process it seems, for most part at least.
Signature · 1 line
Krzysztof Halasa
Quoted 5 lines · Krzysztof Halasa
Quoted 2 lines
I was always curious, why do people want to run ixp4xx in LE mode? What are the benefits that overweight the obvious performance degradation?
Debian is indeed a valid reason.
I wonder if it would be much work to create BE Debian as well.
There _is_ an ARM BE version of Debian.
It's not an official port, but it's not maintained any worse than the 'official' LE ARM Debian port is.
Quoted 4 lines · Lennert Buytenhek
There _is_ an ARM BE version of Debian.
It's not an official port, but it's not maintained any worse than the 'official' LE ARM Debian port is.
Hmm... That changes a bit. Perhaps we should forget about that LE thing then, and (at best) put that trivial workaround?
Signature · 1 line
Krzysztof Halasa
Quoted 9 lines · Krzysztof Halasa
Quoted 4 lines · Lennert Buytenhek
There _is_ an ARM BE version of Debian.
It's not an official port, but it's not maintained any worse than the 'official' LE ARM Debian port is.
Hmm... That changes a bit. Perhaps we should forget about that LE thing then, and (at best) put that trivial workaround?
Does using ixp4xx on LE have any other drawbacks than inferior network performance?
And talking about network performance, what numbers are we talking about (LE vs BE; 30% performance hit on LE, more, or less)?
Signature · 2 lines
Tomasz Chmielewski http://wpkg.org
Quoted 2 lines · Tomasz Chmielewski
Does using ixp4xx on LE have any other drawbacks than inferior network performance?
More memory is needed, something like max 600 KB for 2 Ethernet ports.
Quoted 2 lines
And talking about network performance, what numbers are we talking about (LE vs BE; 30% performance hit on LE, more, or less)?
Haven't checked yet but I'd expect something like that.
Signature · 1 line
Krzysztof Halasa
Quoted 8 lines · Krzysztof Halasa
Quoted 4 lines · Lennert Buytenhek
There _is_ an ARM BE version of Debian.
It's not an official port, but it's not maintained any worse than the 'official' LE ARM Debian port is.
Hmm... That changes a bit. Perhaps we should forget about that LE thing then, and (at best) put that trivial workaround?
Please keep in mind that users are unlikely to install an unofficial port which lacks integration with the Debian infrastructure, security support and other services. The arm architecture (LE) is currently the third most popular in Debian, whereas I suspect (?) there are very few BE Debian systems out there.
Marcus
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Marcus Better schreef:
Quoted 7 lines
Quoted 5 lines · Krzysztof Halasa
Quoted 4 lines · Lennert Buytenhek
There _is_ an ARM BE version of Debian.
It's not an official port, but it's not maintained any worse than the 'official' LE ARM Debian port is.
Quoted 6 lines
Quoted 2 lines
Hmm... That changes a bit. Perhaps we should forget about that LE thing then, and (at best) put that trivial workaround?
Please keep in mind that users are unlikely to install an unofficial port which lacks integration with the Debian infrastructure, security support and other services.
Like the current debian EABI port?
regards,
Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
iD8DBQFGQZBsMkyGM64RGpERAj8HAJ4y0UAXGZBVTPd4VyJAi+/euaGS7gCgi+no QRoEkQEToYgSp+vc8Gtwn2U=
=35DJ
-----END PGP SIGNATURE-----
Quoted 5 lines · Marcus Better
Quoted 4 lines
Quoted 4 lines
There _is_ an ARM BE version of Debian.
It's not an official port, but it's not maintained any worse than the 'official' LE ARM Debian port is.
Quoted 8 lines
Quoted 2 lines
Hmm... That changes a bit. Perhaps we should forget about that LE thing then, and (at best) put that trivial workaround?
Please keep in mind that users are unlikely to install an unofficial port which lacks integration with the Debian infrastructure, security support and other services. The arm architecture (LE) is currently the third most popular in Debian, whereas I suspect (?) there are very few BE Debian systems out there.
Note that all of your arguments also apply to the experimental EABI little-endian ARM port.
I.e.:
1. The EABI port is an unofficial port.
2. The EABI port is not integrated with the Debian infrastructure.
3. The EABI port lacks security support.
You could also argue that:
4. "There is no reason to use EABI -- old-ABI works just as well."
5. "The perceived floating point speedups that EABI gives are completely drowned out by the slowness of the rest of the system."
6. "A lot of programs assume old-ABI behavior, it is too much work to patch them all."
Does that mean that the Debian ARM people have their heads so far up their collective asses that they think that every form of change is bad and are unable to accept that some forms of change might be for the better?
I think you've just summarised why I don't like working on Debian.
Quoted 4 lines · Lennert Buytenhek
Does that mean that the Debian ARM people have their heads so far up their collective asses that they think that every form of change is bad and are unable to accept that some forms of change might be for the better?
Well, I am not one of the Debian ARM people, just a user... and I do hope the EABI port becomes supported in the future! But in the meatime there is a crowd of users running Debian on consumer devices like the NSLU2, and they need a LE network driver.
Marcus
Quoted 9 lines · Marcus Better
Quoted 4 lines
Does that mean that the Debian ARM people have their heads so far up their collective asses that they think that every form of change is bad and are unable to accept that some forms of change might be for the better?
Well, I am not one of the Debian ARM people, just a user... and I do hope the EABI port becomes supported in the future! But in the meatime there is a crowd of users running Debian on consumer devices like the NSLU2, and they need a LE network driver.
"There's a crowd of users running Linux on TCP offload capable cards, and they need TCP offload support in Linux."
The people who need a LE network driver can use Christian's driver, as Christian's driver works in LE just fine. The people who care about LE support can add LE support to the driver that Krzysztof wrote.
I don't think that not supporting LE is a reason not to merge Krzysztof's driver. Don't make supporting LE systems Krzysztof's problem.
Krzysztof has written an excellent driver, and while it would be 100% Debian style to reject his driver just because it doesn't support LE[*], thankfully, Linux is not Debian. Please don't turn Linux into Debian.
[*] And if he were to complain about this, he would get slapped with
the standard "Our priorities are our users and free software" Debian Social Contract rhetoric -- thank $DEITY we don't have a Linux Kernel Social Contract with the same bullshit in it.
Quoted 11 lines · Lennert Buytenhek
The people who need a LE network driver can use Christian's driver, as Christian's driver works in LE just fine. The people who care about LE support can add LE support to the driver that Krzysztof wrote.
I don't think that not supporting LE is a reason not to merge Krzysztof's driver. Don't make supporting LE systems Krzysztof's problem.
Krzysztof has written an excellent driver, and while it would be 100% Debian style to reject his driver just because it doesn't support LE[*], thankfully, Linux is not Debian. Please don't turn Linux into Debian.
I am using the ixp425 on the avila from gateworks. It only has 16 MB of
flash built in. We needed to squeeze a production and a failsafe
linux inside that so debian was not an option. I found intel's original drivers horrible to read, maintain, and use. We are using Cristian's driver (rev 0.2.1) and are preparing to go to his latest for the crypto support. I only had one bug in 0.2.1, which is fixed in later versions.
I would love to see mail line support for this device, including the
ethernet ports and the crypto capabilities.
We run in big endian despite the extra difficulty in toolset setup and finding lots of brain0-damaged-designed-for-x86 code. We already can use up the CPU when we have the mini-pci slots populated with 802.11g radios and the ethernet port in use. Swapping packets would kill us. Never mind if we do any kind of software based crypto! For those of us in the embedded space, performance matters.
Big endian is the natural setup for the NPEs on this hardware according to the intel documentation. Please don't stop this driver from moving forward so that a few folks can run their hardware in slow mode.
-Ack
Quoted 1 line · David Acker
Big endian is the natural setup for the NPEs on this hardware according to the intel documentation. Please don't stop this driver from moving forward so that a few folks can run their hardware in slow mode.
No-one is saying that this driver should not be mainlined before it has LE support. All that I said was:
Quoted 1 line
Personally I'd like LE ethernet tested and working before we push.
The alternative would be to explicitly state in Kconfig that LE arm is broken with this driver, so that this could be fixed later.
Please can we not blow this out of proportion, it really isn't that big a deal. The irony is that fixing Krzysztof's driver to work on LE will probably be quite easy, given that we already have a working LE driver from Christian.
Michael-Luke
PS: It really isn't just 'a few folks' - at NSLU2-Linux we have 5000 people who have downloaded Debian/LE for NSLU2 and are currently using Christian's driver with great success. We would just like to replicate that support with this new driver.
Quoted 7 lines · Michael-Luke Jones
No-one is saying that this driver should not be mainlined before it has LE support. All that I said was:
Quoted 1 line
Personally I'd like LE ethernet tested and working before we push.
The alternative would be to explicitly state in
Kconfigthat LE arm is broken with this driver, so that this could be fixed later.
The driver does bomb out during compile if __ARMEB__ isn't defined, but that apparently wasn't good enough.
Quoted 4 lines
Please can we not blow this out of proportion, it really isn't that big a deal. The irony is that fixing Krzysztof's driver to work on LE will probably be quite easy, given that we already have a working LE driver from Christian.
I'm looking forward to your patch.
Quoted 1 line · Tomasz Chmielewski
Krzysztof, why is LE not supported?
I'm not yet sure how to do it best.
The trivial way is really trivial, allocate a set of 1536-byte buffers and make a swap+copy on RX and TX, but I want to investigate the data-coherent approach first.
Quoted 1 line
Do you need access to ixp4xx that starts in LE mode?
No, I have a nice experimental machine so there is no problem with that. I'd have to recompile my tools (GNU suite and rest of the system) LE, but it's a simple thing, too.
I just want to have the functional drivers in the tree and only then improve them. Doing all the work in a single step is just impossible, the target moves way too fast (at least for my limited time budget).
Signature · 1 line
Krzysztof Halasa
Quoted 15 lines · Tomasz Chmielewski
Quoted 10 lines · Michael Jones
Review
Quoted 3 lines
(quoted diff) +3
-0+#ifndef __ARMEB__ +#warning Little endian mode not supported +#endifPersonally I'm less fussed about WAN / LE support. Anyone with any sense will run ixp4xx boards doing such a specialised network operation as BE. Also, NSLU2-Linux can't test this functionality with our LE setup as we don't have this hardware on-board. You may just want to declare a depends on ARMEB in
Kconfig(with or without OR (ARM || BROKEN) ) and have done with it - it's up to you.Christian Hohnstaedt's work did support LE though.
Quoted 7 lines
Not all ixp4xx boards are by definition "doing such a specialised network operation".
Krzysztof, why is LE not supported?
Do you need access to ixp4xx that starts in LE mode?
Not even trying to support LE is a clear merge blocker. Maybe Krzysztof can't actually test it himself, which is fine - but not even pretending to be endian clean is not what proper Linux drivers do.
Quoted 3 lines · Christoph Hellwig
Not even trying to support LE is a clear merge blocker. Maybe Krzysztof can't actually test it himself, which is fine - but not even pretending to be endian clean is not what proper Linux drivers do.
w.r.t this comment, a working implementation LE implementation can be viewed here:
http://www.hohnstaedt.de/ixp_npe/0.3.1/ixp4xx_npe_driver-0.3.1.diff
Search in this file for "swap the payload of the SKB" (it's in mac_driver.c)
Michael-Luke Jones
Quoted 16 lines · Christoph Hellwig
Quoted 16 lines
Quoted 10 lines
Review
Quoted 3 lines
(quoted diff) +3
-0+#ifndef __ARMEB__ +#warning Little endian mode not supported +#endifPersonally I'm less fussed about WAN / LE support. Anyone with any sense will run ixp4xx boards doing such a specialised network operation as BE. Also, NSLU2-Linux can't test this functionality with our LE setup as we don't have this hardware on-board. You may just want to declare a depends on ARMEB in
Kconfig(with or without OR (ARM || BROKEN) ) and have done with it - it's up to you.Christian Hohnstaedt's work did support LE though.
Not all ixp4xx boards are by definition "doing such a specialised network operation".
Quoted 8 lines
Quoted 3 lines
Krzysztof, why is LE not supported?
Do you need access to ixp4xx that starts in LE mode?
Not even trying to support LE is a clear merge blocker. Maybe Krzysztof can't actually test it himself, which is fine - but not even pretending to be endian clean is not what proper Linux drivers do.
The issue is not that the driver is not 'endian clean'.
This is a driver for an on-chip ethernet MAC on an ARM CPU. I.e. the ethernet MAC is on the CPU itself, it's not some kind of PCI device or something like that. The ARM CPU in question can be run in either little endian or big endian mode. Making a driver work in both modes of operation is generally not just an issue of adding a couple of be32_to_cpu()s in the right places.
For example, intel IXP2000 and IXP23xx CPU support in arch/arm only supports big-endian mode of operation, and none of the associated drivers support little-endian mode.
Most of the other CPU support in arch/arm only supports little-endian mode, and none of the associated drivers support big-endian mode. According to your criterion, that would mean that most of the ARM drivers (alsa, usb, framebuffer, networking, etc.) should never have been accepted in the kernel tree in the first place.
Quoted 3 lines · Lennert Buytenhek
Making a driver work in both modes
of operation is generally not just an issue of adding a couple of be32_to_cpu()s in the right places.
While this comment is technically correct, Christian's driver achieves endian agnostic operation with only 10 additional lines of code [1].
Thus, there is no reason to assume that gaining LE support will be a major issue.
Michael-Luke
[1] http://www.hohnstaedt.de/ixp_npe/0.3.1/ixp4xx_npe_driver-0.3.1.diff
Search in this file for "swap the payload of the SKB" (it's in mac_driver.c)
Quoted 1 line · Lots of people
Lots of huffing and puffing about endian support by this driver ...
For what it's worth, the NSLU2-Linux project (which has over 10,000 known users of our custom ixp4xx firmware, most of which will eventually be users of this new driver) is *endian-neutral*.
We support both big-endian and little-endian usage of the ixp4xx in a number of consumer devices like the NSLU2, NAS100d, DSMG600, and FSG3.
We are very interested in getting this driver into mainline in the most expedient and correct fashion acceptable to the relevant mainline maintainers. We have also discussed this situation with the author of the previous set of ixp4xx open-source ethernet driver patches, and he also recommends that we put our support behind this new set of patches.
So, if the author of these patches wishes to concentrate on big-endian support first, then we will not say (and have not said) anything which will block inclusion of a big-endian only version of this driver.
In parallel to this initial upstream push, we will be working with the author to make sure that this driver supports little-endian devices as well (as we are endian-neutral in our project's support of consumer devices based on the ixp4xx). If we get this done before upstream acceptance of the big-endian version, that will be great. If we don't, then we'll work to hit the next merge window. We will create a functionally correct little-endian version first (the simple byte-swapping implementation) and will work on a performance-enhanced version later (if that is even possible without prohibitive massive upstream changes).
There simply is no reason for everyone to be arguing about this.
Remember that what we are seeing here is an open-source replacement for a long-time proprietary driver. We should all rejoice in that, support the author of these patches, and not fight amongst ourselves.
-- Rod Whitby
-- NSLU2-Linux Project Lead
Quoted 3 lines · Rod Whitby
So, if the author of these patches wishes to concentrate on big-endian support first, then we will not say (and have not said) anything which will block inclusion of a big-endian only version of this driver.
The NSLU2 people are the ones here that are saying that the driver should really support LE (because that is what they happen to be using, the rest of the world runs the ixp4xx in BE), and they keep saying that it would be so easy to make a patch to add LE support, but so far they haven't produced such a patch.
Please just write the patch and let's get this over with.
Quoted 8 lines · Lennert Buytenhek
Quoted 3 lines · Rod Whitby
So, if the author of these patches wishes to concentrate on big-endian support first, then we will not say (and have not said) anything which will block inclusion of a big-endian only version of this driver.
The NSLU2 people are the ones here that are saying that the driver should really support LE (because that is what they happen to be using, the rest of the world runs the ixp4xx in BE)
I'll repeat again. NSLU2-Linux supports both BE and LE. We have about 5,000 users running BE and about 5,000 users running LE. Perhaps you're confusing the NSLU2-Linux project (which official supports both endians equally) with the Debian project (which official supports only LE, and has an unofficial BE port).
One NSLU2-Linux person said they would prefer the driver to support LE, but would be happy for it to be marked BE only in the Kconfig as an alternative. That is consistent with what I wrote in my message.
Quoted 1 line
Please just write the patch and let's get this over with.
Please let's just stop arguing about it. If a patch appears before it gets merged, then great. If it doesn't then it will appear at a later date.
-- Rod
Quoted 10 lines · Rod Whitby
Quoted 7 lines
Quoted 3 lines
So, if the author of these patches wishes to concentrate on big-endian support first, then we will not say (and have not said) anything which will block inclusion of a big-endian only version of this driver.
The NSLU2 people are the ones here that are saying that the driver should really support LE (because that is what they happen to be using, the rest of the world runs the ixp4xx in BE)
I'll repeat again. NSLU2-Linux supports both BE and LE. We have about 5,000 users running BE and about 5,000 users running LE.
Perhaps, but somehow I don't think that we'd have seen any reaction if the submitted driver had only supported LE and not BE.
Quoted 5 lines
Quoted 1 line
Please just write the patch and let's get this over with.
Please let's just stop arguing about it. If a patch appears before it gets merged, then great. If it doesn't then it will appear at a later date.
Great. I agree.
Quoted 2 lines · Rod Whitby
Please let's just stop arguing about it. If a patch appears before it gets merged, then great. If it doesn't then it will appear at a later date.
Sure. The "swapping" patch is trivial and I can add it if needed at some point but I hope we can do that "data coherency mode" right.
Personally I'd be pleased if I could run the board LE instead of BE, with no performance penalty.
Signature · 1 line
Krzysztof Halasa
Quoted 3 lines · Christoph Hellwig
Not even trying to support LE is a clear merge blocker. Maybe Krzysztof can't actually test it himself, which is fine - but not even pretending to be endian clean is not what proper Linux drivers do.
The drivers can only work with IXP4xx CPU and that's not the typical endianess problem cross-platform drivers sometimes have.
There is different functionality required with LE mode, unless some other arch changes are implemented (which I'm now researching, if I have some time of course).
Signature · 1 line
Krzysztof Halasa