Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, better answer late, than never.. To conclude: We won't get to a common opinion on that I guess. I just wanted to draw your attention (from time to time, maybe once a year) onto that this 0,52% IPv6-stuff isn't real life, honestly. 99,48% are v4-only, thats just a fact, there is no v6 outside Testbeds and Freaks (and I count myself as freak, but I don't use it productive because I cannot spend 12hrs a day with all the problems it implies) Am 23.04.2012 11:26, schrieb Gert Doering: Hi, On Mon, Apr 23, 2012 at 01:49:18AM +0200, Michael Markstaller wrote: Appreciate your work really but just my 5ct: noone needs IPv6 if not in search for troubles or many new (security)-problems. Welcome to the 21st century. There are ISPs in Asia today(!) that *will* *not* give you an IPv4 address, because they have none left. Thats egostic now but: is this my problem? No, my problems are everyday stuff in common and existing IPv4 networks.. So with a workload of 110% an IPv6 migration will make things better? Won't guess ;) I love the --disable-ipv6 switch, please keep it working without this experiment, I guess there are many other fields to work on - with more relationship to real-life :o IPv6 is most relevant to real-life. see above, which real life, sorry, I still havent any customer asking for, that *is* real life. Things are made by business and money - I don't like that though, I'd rather prefer to get the time to migrate anyone I know to IPv6 but thats not the truth of life.. As soon as an v4 /24 costs more than migrating a large network to v6, I'd agree that it is real life Many of the problems we see in IPv6 deployments are caused exactly by this attitude - instead of *using* it and fixing the problems that are still left, disabling it and hoping that it won't be needed before personal retirement. This won't get any of the issues fixed, and one day you'll find yourself in need of IPv6, and the problems are still there. I understand your concerns and share them absolutely! It was right after we met (many) years ago, I started v6 internally, but honestly, I can only do this as a hobby (and I *do*) - for production I have to make sure things work 24x7, my customers dont care if I use v4, v6 or NetBEUI - if it works :p And just to givean example: after upgrading to Windows 12.04 on my Notebook last week, I had to disable v6 to make Wlanlan work concurrently as it detected duplicated v6-IPs with the mac of the wlan (no v6 active at all in this net) - there are still many things broken. On this Friday morning I just had to work, not chase v6-issues.. - - I'll file a bug for that surely (and first search 30min if it doesn't exist already) but that takes some minutes to qualify that. So, finally please understand also, that there is a 99,48%-world besides v6 which has to work as it is. Michael P.S.: I promise to put up v6 again and report what I find, I just ask to remind the latest point ;) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+lvNAACgkQaWRHV2kMuAJgKACgup/C4J+wyDh6loclYRyyyO2N s8sAoIc3TFQkENInSRarqYBqLi1JBzL7 =Eg4i -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 So, finally please understand also, that there is a 99,48%-world besides v6 which has to work as it is. Finally, please understand that your IPv6 discussion in this thread is pointless, off topic and and unproductive. It draws attention away from the main objective, which is eliminating bottlenecks in the packet processing path. Neither has the proposed patch set anything to do with any - --disable-ipv6 switch nor has it any implications on IPv6 security or deployment scenarios. If you have specific problems with IPv6 being enabled then feel free to discuss it in a separate thread. ~ Jow -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+lvpAACgkQdputYINPTPMYuQCff/26OhJyiDodcEeg+aI0fGto vT0Anj4QLjSdcGp5TU3kLkLCdfdzHRwE =99oq -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx
On 4/30/12 12:34 PM, Felix Fietkau wrote: On 2012-04-30 8:11 PM, Dave Taht wrote: On Mon, Apr 30, 2012 at 10:26 AM, Felix Fietkau n...@openwrt.org wrote: I agree it would blow up the dcache and be worse than what exists by a lot. So, out of this conversation: 1) It would be nice to not have this patch take effect on any but the ar71xx and ar91xx. As these share code in openwrt, doing it with a compile time define Right. For upstreaming parts of this stuff, this would definitely be necessary. 2) IF there existed another brain damaged ethernet chip on some other arch, it would be worth coming up with a Kbuild option to enable defining __packed generically as part of the network stack for those arches. Something more pithy than #define F_ING_HW_ENGINEER_SAVED_PIN would be needed tho. #define UNALIGNED_ETHERNET perhaps. There could be a generic Kconfig variable which could be selected by CPU targets or ethernet drivers (with a dependency on !HAVE_EFFICIENT_UNALIGNED_ACCESS). That's cleaner than messing around with #define stuff manually. 3) I don't like the tcp_hdr macro in general, but it looks like that is an obsolete part of the patch anyway, so I'll try ripping it out. 4) get_unaligned_be32 seems like the right thing rather than get_unaligned_cpu32? Right. 5) I THINK the 'if aligned, do assembly version' for the checksums is a win, but if item #2 is true, I'm not happy with the casts... @@ -105,6 +141,9 @@ static inline __sum16 ip_fast_csum(const void *iph, unsigned int ihl) unsigned int csum; int carry; + if ((unsigned int) iph 3) + return ip_fast_csum_unaligned(iph,ihl); + For casts from pointers to integers, the kernel typically uses unsigned long instead of unsigned int. - Felix The kernel has a specific type for this: include/linux/types.h:typedef unsigned long uintptr_t; ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx
On Sun, 2012-04-22 at 14:48 -0700, Dave Täht wrote: + +-#define tcp_flag_word(tp) ( ((union tcp_word_hdr *)(tp))-words [3]) ++#define tcp_flag_word2(tp) ( ((union tcp_word_hdr *)(tp))-words [3]) ++#define tcp_flag_word(tp) ( __get_unaligned_cpu32union tcp_word_hdr *)(tp))-words [3]))) Ewww. And didn't you already make that union __packed anyway? +diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c +index 22ef5f9..bf3f773 100644 +--- a/net/ipv4/tcp.c b/net/ipv4/tcp.c +@@ -2834,7 +2834,7 @@ found: + + p = *head; + th2 = tcp_hdr(p); +- tcp_flag_word(th2) |= flags (TCP_FLAG_FIN | TCP_FLAG_PSH); ++ tcp_flag_word2(th2) = tcp_flag_word(th2) | flags (TCP_FLAG_FIN | TCP_FLAG_PSH); net/ipv4/tcp.c: In function 'tcp_gro_receive': net/ipv4/tcp.c:2837:82: warning: suggest parentheses around arithmetic in operand of '|' [-Wparentheses] Have you posted these patches to the netdev list? And is the response going to be just make sure your network devices are receiving packets into sensibly-aligned buffers, and none of this is necessary? There's a reason a lot of Ethernet drivers pad the start of their skb by 2 bytes before receiving the packet... -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx
On Mon, Apr 30, 2012 at 3:49 AM, David Woodhouse dw...@infradead.org wrote: On Sun, 2012-04-22 at 14:48 -0700, Dave Täht wrote: Thank you very much for the code review! + +-#define tcp_flag_word(tp) ( ((union tcp_word_hdr *)(tp))-words [3]) ++#define tcp_flag_word2(tp) ( ((union tcp_word_hdr *)(tp))-words [3]) ++#define tcp_flag_word(tp) ( __get_unaligned_cpu32union tcp_word_hdr *)(tp))-words [3]))) Ewww. And didn't you already make that union __packed anyway? yes, ewww. I'll note that I don't like the define in the general case. It is used both for assignment (once!) and for access , which is why it got broken into two macros... +diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c +index 22ef5f9..bf3f773 100644 +--- a/net/ipv4/tcp.c b/net/ipv4/tcp.c +@@ -2834,7 +2834,7 @@ found: + + p = *head; + th2 = tcp_hdr(p); +- tcp_flag_word(th2) |= flags (TCP_FLAG_FIN | TCP_FLAG_PSH); ++ tcp_flag_word2(th2) = tcp_flag_word(th2) | flags (TCP_FLAG_FIN | TCP_FLAG_PSH); net/ipv4/tcp.c: In function 'tcp_gro_receive': net/ipv4/tcp.c:2837:82: warning: suggest parentheses around arithmetic in operand of '|' [-Wparentheses] Have you posted these patches to the netdev list? And is the response going to be just make sure your network devices are receiving packets into sensibly-aligned buffers, and none of this is necessary? Yes, that would be the answer I expect from the list. There is no reason to try to push this stuff upstream. There's a reason a lot of Ethernet drivers pad the start of their skb by 2 bytes before receiving the packet... Tell it to however wired up this chip and shipped it in qty millions. Actually that message was already received, successor chipsets from this manufacturer did it up right. I am somewhat forgiving in that. Compared to some arches I've worked with the ar71xx is very solid. (for comparison, take the ep9302, where a working toolchain didn't arrive until 2 years after the chip had ceased production) But this problem is a PITA, and as demonstrated, scribbling on these core portions of the stack improves performance by an enormous amount. -- dwmw2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- Dave Täht SKYPE: davetaht US Tel: 1-239-829-5608 http://www.bufferbloat.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx
On Mon, 2012-04-30 at 07:41 -0700, Dave Taht wrote: Tell it to however wired up this chip and shipped it in qty millions. Actually that message was already received, successor chipsets from this manufacturer did it up right. So the real problem is that the ar71xx doesn't allow you to DMA to addresses which aren't aligned to 4 bytes? Which network devices does that restriction apply to? All of them? Out of interest, have you done a performance comparison with just *moving* the packet when it arrives? If this really is needed to work around hardware limitations, I don't see why *some* of it shouldn't be acceptable upstream. A config option to add '__packed' to various structures is fairly harmless, for example... -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx
On 2012-04-30 4:49 PM, David Woodhouse wrote: On Mon, 2012-04-30 at 07:41 -0700, Dave Taht wrote: Tell it to however wired up this chip and shipped it in qty millions. Actually that message was already received, successor chipsets from this manufacturer did it up right. So the real problem is that the ar71xx doesn't allow you to DMA to addresses which aren't aligned to 4 bytes? Which network devices does that restriction apply to? All of them? AR71xx and AR91xx are affected, AR724x, AR933x, AR934x are unaffected. Out of interest, have you done a performance comparison with just *moving* the packet when it arrives? I did some tests before I did the first unaligned hack patch, I don't have the numbers anymore, but the results were horrible. If this really is needed to work around hardware limitations, I don't see why *some* of it shouldn't be acceptable upstream. A config option to add '__packed' to various structures is fairly harmless, for example... Makes sense - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx
On Mon, Apr 30, 2012 at 7:49 AM, David Woodhouse dw...@infradead.org wrote: On Mon, 2012-04-30 at 07:41 -0700, Dave Taht wrote: Tell it to however wired up this chip and shipped it in qty millions. Actually that message was already received, successor chipsets from this manufacturer did it up right. So the real problem is that the ar71xx doesn't allow you to DMA to addresses which aren't aligned to 4 bytes? Which network devices does that restriction apply to? All of them? Out of interest, have you done a performance comparison with just *moving* the packet when it arrives? I did not. Felix did. Fixing this issue has had a long, tortuous history... this got tried and later backed out... https://dev.openwrt.org/changeset/20892 - on ar724x, rx buffers can be aligned with an offset of 2, which keeps the ip header aligned - alignment offset is only added if the ar8216 workaround is not active and the phy driver does not advertise its own packet alignment - ar71xx and ar91xx can not handle rx alignment offsets, however taking a hit on unaligned exceptions seems to have less overhead than re-aligning the data for large packets - use memmove to re-align small packets, if necessary tested on ar9132, ar7240 and ar7242 based devices without ar8216 headers Which got backed out here: https://dev.openwrt.org/ticket/7236 So I'd certainly be willing to attempt realignment in the driver, and sort of remember that it's like a one-liner to do nowadays... but it is a 16 bit bus, and packets are dmaed, so getting the cpu involved on every ethernet transfer strikes me as potentially very bad. If this really is needed to work around hardware limitations, I don't see why *some* of it shouldn't be acceptable upstream. A config option to add '__packed' to various structures is fairly harmless, for example... The __packed trick, so far as I know, is undefined gcc behavior. But, yea, perhaps something more PC than this #define F_ING_HW_ENGINEER_SAVED_A_PIN __packed -- dwmw2 -- Dave Täht SKYPE: davetaht US Tel: 1-239-829-5608 http://www.bufferbloat.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx
On Mon, Apr 30, 2012 at 8:02 AM, Felix Fietkau n...@openwrt.org wrote: On 2012-04-30 4:49 PM, David Woodhouse wrote: On Mon, 2012-04-30 at 07:41 -0700, Dave Taht wrote: Tell it to however wired up this chip and shipped it in qty millions. Actually that message was already received, successor chipsets from this manufacturer did it up right. So the real problem is that the ar71xx doesn't allow you to DMA to addresses which aren't aligned to 4 bytes? Which network devices does that restriction apply to? All of them? AR71xx and AR91xx are affected, AR724x, AR933x, AR934x are unaffected. I guess a long term issue is this patch needs to apply only to those arches, somehow. It's silly to be hurtful to the successor arches. Out of interest, have you done a performance comparison with just *moving* the packet when it arrives? I did some tests before I did the first unaligned hack patch, I don't have the numbers anymore, but the results were horrible. I'm still looking for the 'one liner to pass the driver to tell it to realign', but was that the approach you were trying... If this really is needed to work around hardware limitations, I don't see why *some* of it shouldn't be acceptable upstream. A config option to add '__packed' to various structures is fairly harmless, for example... Makes sense - Felix -- Dave Täht SKYPE: davetaht US Tel: 1-239-829-5608 http://www.bufferbloat.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx
On 2012-04-30 5:08 PM, Dave Taht wrote: On Mon, Apr 30, 2012 at 8:02 AM, Felix Fietkau n...@openwrt.org wrote: On 2012-04-30 4:49 PM, David Woodhouse wrote: On Mon, 2012-04-30 at 07:41 -0700, Dave Taht wrote: Tell it to however wired up this chip and shipped it in qty millions. Actually that message was already received, successor chipsets from this manufacturer did it up right. So the real problem is that the ar71xx doesn't allow you to DMA to addresses which aren't aligned to 4 bytes? Which network devices does that restriction apply to? All of them? AR71xx and AR91xx are affected, AR724x, AR933x, AR934x are unaffected. I guess a long term issue is this patch needs to apply only to those arches, somehow. It's silly to be hurtful to the successor arches. Out of interest, have you done a performance comparison with just *moving* the packet when it arrives? I did some tests before I did the first unaligned hack patch, I don't have the numbers anymore, but the results were horrible. I'm still looking for the 'one liner to pass the driver to tell it to realign', but was that the approach you were trying... I did test with such a one liner (or maybe it was a two liner), but I didn't keep the patch. I think it's quite normal that this approach is so much more expensive than adding the unaligned access hacks. The main bottleneck on these devices is the memory bus, and for normal traffic passed through the device as a router, the CPU does not have to touch much of the payload contents at all, since it's only touched by DMA. Doing a memmove to re-align the packet contents blows the dcache footprint out of proportion and significantly increases the amount of unnecessary memory bus traffic. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx
On Mon, Apr 30, 2012 at 10:26 AM, Felix Fietkau n...@openwrt.org wrote: On 2012-04-30 5:08 PM, Dave Taht wrote: On Mon, Apr 30, 2012 at 8:02 AM, Felix Fietkau n...@openwrt.org wrote: On 2012-04-30 4:49 PM, David Woodhouse wrote: On Mon, 2012-04-30 at 07:41 -0700, Dave Taht wrote: Tell it to however wired up this chip and shipped it in qty millions. Actually that message was already received, successor chipsets from this manufacturer did it up right. So the real problem is that the ar71xx doesn't allow you to DMA to addresses which aren't aligned to 4 bytes? Which network devices does that restriction apply to? All of them? AR71xx and AR91xx are affected, AR724x, AR933x, AR934x are unaffected. I guess a long term issue is this patch needs to apply only to those arches, somehow. It's silly to be hurtful to the successor arches. Out of interest, have you done a performance comparison with just *moving* the packet when it arrives? I did some tests before I did the first unaligned hack patch, I don't have the numbers anymore, but the results were horrible. I'm still looking for the 'one liner to pass the driver to tell it to realign', but was that the approach you were trying... I did test with such a one liner (or maybe it was a two liner), but I didn't keep the patch. I think it's quite normal that this approach is so much more expensive than adding the unaligned access hacks. The main bottleneck on these devices is the memory bus, and for normal traffic passed through the device as a router, the CPU does not have to touch much of the payload contents at all, since it's only touched by DMA. Doing a memmove to re-align the packet contents blows the dcache footprint out of proportion and significantly increases the amount of unnecessary memory bus traffic. I agree it would blow up the dcache and be worse than what exists by a lot. So, out of this conversation: 1) It would be nice to not have this patch take effect on any but the ar71xx and ar91xx. As these share code in openwrt, doing it with a compile time define 2) IF there existed another brain damaged ethernet chip on some other arch, it would be worth coming up with a Kbuild option to enable defining __packed generically as part of the network stack for those arches. Something more pithy than #define F_ING_HW_ENGINEER_SAVED_PIN would be needed tho. #define UNALIGNED_ETHERNET perhaps. 3) I don't like the tcp_hdr macro in general, but it looks like that is an obsolete part of the patch anyway, so I'll try ripping it out. 4) get_unaligned_be32 seems like the right thing rather than get_unaligned_cpu32? 5) I THINK the 'if aligned, do assembly version' for the checksums is a win, but if item #2 is true, I'm not happy with the casts... @@ -105,6 +141,9 @@ static inline __sum16 ip_fast_csum(const void *iph, unsigned int ihl) unsigned int csum; int carry; + if ((unsigned int) iph 3) + return ip_fast_csum_unaligned(iph,ihl); + - Felix -- Dave Täht SKYPE: davetaht US Tel: 1-239-829-5608 http://www.bufferbloat.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx
On 2012-04-30 8:11 PM, Dave Taht wrote: On Mon, Apr 30, 2012 at 10:26 AM, Felix Fietkau n...@openwrt.org wrote: On 2012-04-30 5:08 PM, Dave Taht wrote: On Mon, Apr 30, 2012 at 8:02 AM, Felix Fietkau n...@openwrt.org wrote: On 2012-04-30 4:49 PM, David Woodhouse wrote: On Mon, 2012-04-30 at 07:41 -0700, Dave Taht wrote: Tell it to however wired up this chip and shipped it in qty millions. Actually that message was already received, successor chipsets from this manufacturer did it up right. So the real problem is that the ar71xx doesn't allow you to DMA to addresses which aren't aligned to 4 bytes? Which network devices does that restriction apply to? All of them? AR71xx and AR91xx are affected, AR724x, AR933x, AR934x are unaffected. I guess a long term issue is this patch needs to apply only to those arches, somehow. It's silly to be hurtful to the successor arches. Out of interest, have you done a performance comparison with just *moving* the packet when it arrives? I did some tests before I did the first unaligned hack patch, I don't have the numbers anymore, but the results were horrible. I'm still looking for the 'one liner to pass the driver to tell it to realign', but was that the approach you were trying... I did test with such a one liner (or maybe it was a two liner), but I didn't keep the patch. I think it's quite normal that this approach is so much more expensive than adding the unaligned access hacks. The main bottleneck on these devices is the memory bus, and for normal traffic passed through the device as a router, the CPU does not have to touch much of the payload contents at all, since it's only touched by DMA. Doing a memmove to re-align the packet contents blows the dcache footprint out of proportion and significantly increases the amount of unnecessary memory bus traffic. I agree it would blow up the dcache and be worse than what exists by a lot. So, out of this conversation: 1) It would be nice to not have this patch take effect on any but the ar71xx and ar91xx. As these share code in openwrt, doing it with a compile time define Right. For upstreaming parts of this stuff, this would definitely be necessary. 2) IF there existed another brain damaged ethernet chip on some other arch, it would be worth coming up with a Kbuild option to enable defining __packed generically as part of the network stack for those arches. Something more pithy than #define F_ING_HW_ENGINEER_SAVED_PIN would be needed tho. #define UNALIGNED_ETHERNET perhaps. There could be a generic Kconfig variable which could be selected by CPU targets or ethernet drivers (with a dependency on !HAVE_EFFICIENT_UNALIGNED_ACCESS). That's cleaner than messing around with #define stuff manually. 3) I don't like the tcp_hdr macro in general, but it looks like that is an obsolete part of the patch anyway, so I'll try ripping it out. 4) get_unaligned_be32 seems like the right thing rather than get_unaligned_cpu32? Right. 5) I THINK the 'if aligned, do assembly version' for the checksums is a win, but if item #2 is true, I'm not happy with the casts... @@ -105,6 +141,9 @@ static inline __sum16 ip_fast_csum(const void *iph, unsigned int ihl) unsigned int csum; int carry; + if ((unsigned int) iph 3) + return ip_fast_csum_unaligned(iph,ihl); + For casts from pointers to integers, the kernel typically uses unsigned long instead of unsigned int. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx
On Mon, 2012-04-30 at 11:11 -0700, Dave Taht wrote:
On Mon, Apr 30, 2012 at 10:26 AM, Felix Fietkau n...@openwrt.org wrote:
On 2012-04-30 5:08 PM, Dave Taht wrote:
On Mon, Apr 30, 2012 at 8:02 AM, Felix Fietkau n...@openwrt.org wrote:
On 2012-04-30 4:49 PM, David Woodhouse wrote:
On Mon, 2012-04-30 at 07:41 -0700, Dave Taht wrote:
Tell it to however wired up this chip and shipped it in qty millions.
Actually that message was already received, successor chipsets from
this manufacturer did it up right.
So the real problem is that the ar71xx doesn't allow you to DMA to
addresses which aren't aligned to 4 bytes? Which network devices does
that restriction apply to? All of them?
AR71xx and AR91xx are affected, AR724x, AR933x, AR934x are unaffected.
I guess a long term issue is this patch needs to apply only to those
arches,
somehow. It's silly to be hurtful to the successor arches.
Out of interest, have you done a performance comparison with just
*moving* the packet when it arrives?
I did some tests before I did the first unaligned hack patch, I don't
have the numbers anymore, but the results were horrible.
I'm still looking for the 'one liner to pass the driver to tell it to
realign',
but was that the approach you were trying...
I did test with such a one liner (or maybe it was a two liner), but I
didn't keep the patch.
I think it's quite normal that this approach is so much more expensive
than adding the unaligned access hacks. The main bottleneck on these
devices is the memory bus, and for normal traffic passed through the
device as a router, the CPU does not have to touch much of the payload
contents at all, since it's only touched by DMA.
Doing a memmove to re-align the packet contents blows the dcache
footprint out of proportion and significantly increases the amount of
unnecessary memory bus traffic.
I agree it would blow up the dcache and be worse than what exists by a lot.
So, out of this conversation:
1) It would be nice to not have this patch take effect on any but the
ar71xx and ar91xx. As these share code in openwrt, doing it with a
compile time define
This bothers me. It sounds like you don't even *care* about getting code
merged upstream. I know it's potentially hard in this case, but it
should still be the default mode.
A good start would be to have patches that aren't platform-specific, and
can be applied across the board.
2) IF there existed another brain damaged ethernet chip on some other
arch,
There are certainly plenty of architectures where alignment traps are
very expensive, and a fair number of brain-damaged network devices that
can't ensure their packets end up suitably aligned, either. I think it's
sane enough to at least *try* talking to DaveM about a condition
'__packed' on the relevant structures, and a simple 'load __be32' and
'load __u32' operation that may or may not explicitly use unaligned
loads according to the same config option.
it would be worth coming up with a Kbuild option to enable
defining __packed generically as part of the network stack for those
arches. Something more
pithy than
#define F_ING_HW_ENGINEER_SAVED_PIN
would be needed tho.
#define UNALIGNED_ETHERNET
Network, not Ethernet. But yeah, something like that.
perhaps.
3) I don't like the tcp_hdr macro in general, but it looks like that
is an obsolete part of the patch anyway, so I'll try ripping it out.
Sounds good.
There are also a bunch of 16-bit loads that are being patched — is there
any point in that? Surely the packets are still aligned to *2* bytes?
This one looks suspicious too:
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -17,7 +17,10 @@ static void iph_to_flow_copy_addrs(struct flow_keys *flow, co
nst struct iphdr *i
{
BUILD_BUG_ON(offsetof(typeof(*flow), dst) !=
offsetof(typeof(*flow), src) + sizeof(flow-src));
- memcpy(flow-src, iph-saddr, sizeof(flow-src) + sizeof(flow-dst));
+ /* memcpy(flow-src, iph-saddr, sizeof(flow-src) +
sizeof(flow-dst)); */
+ flow-src = iph-saddr;
+ flow-dst = iph-daddr;
+
}
4) get_unaligned_be32 seems like the right thing rather than
get_unaligned_cpu32?
In some cases, yes. I actually think you should define specific macros
which do each, and their behaviour is just a straight dereference if
CONFIG_NETWORK_UNALIGNED is not set.
5) I THINK the 'if aligned, do assembly version' for the checksums is
a win, but if item #2 is true, I'm not happy with the casts...
@@ -105,6 +141,9 @@ static inline __sum16 ip_fast_csum(const void
*iph, unsigned int ihl)
unsigned int csum;
int carry;
+ if ((unsigned int) iph 3)
+ return ip_fast_csum_unaligned(iph,ihl);
+
At least that one is in MIPS-specific code, so it's easier to stomach.
But yeah, cast it to 'unsigned long'. And why not write an assembly
routine that copes with unaligned
Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx
On Mon, 2012-04-30 at 20:34 +0200, Felix Fietkau wrote: There could be a generic Kconfig variable which could be selected by CPU targets or ethernet drivers (with a dependency on !HAVE_EFFICIENT_UNALIGNED_ACCESS). That's cleaner than messing around with #define stuff manually. Don't just select it; you *might* have a crappy network driver that can't insert padding to align its packets, but you might not care about performance for that particular device — you might use it for a low-traffic interface or something, or not use it at all. It's a user choice, I think. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx
On 04/30/2012 06:48 PM, David Woodhouse wrote: On Mon, 2012-04-30 at 20:34 +0200, Felix Fietkau wrote: There could be a generic Kconfig variable which could be selected by CPU targets or ethernet drivers (with a dependency on !HAVE_EFFICIENT_UNALIGNED_ACCESS). That's cleaner than messing around with #define stuff manually. Don't just select it; you *might* have a crappy network driver that can't insert padding to align its packets, but you might not care about performance for that particular device — you might use it for a low-traffic interface or something, or not use it at all. It's a user choice, I think. As a user, I _never_ want to have to go and turn on the switch that says, make my device work as fast as it can Is there any reason that I would _not_ want this? Not caring about performance is not a good reason to not provide performance. Cheers, Karl P ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx
On Mon, 2012-04-30 at 19:16 +, Karl P wrote: As a user, I _never_ want to have to go and turn on the switch that says, make my device work as fast as it can Is there any reason that I would _not_ want this? You may only have a printer, or something like that, attached to the crappy Ethernet port. And hacking the entire network stack to load integers byte-by-byte instead of doing 32-bit loads may have an adverse effect on the performance of the decent interfaces that you *do* care about. Do we have numbers on how much the performance *decrease* is, for decent network devices that *do* actually align their packets sanely? -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx
On Sun, 2012-04-22 at 14:48 -0700, Dave Täht wrote: +--- a/net/ipv6/netfilter/ip6t_LOG.c b/net/ipv6/netfilter/ip6t_LOG.c +@@ -64,9 +64,9 @@ static void dump_packet(struct sbuff *m, + /* Max length: 44 LEN=65535 TC=255 HOPLIMIT=255 FLOWLBL=F */ + sb_add(m, LEN=%Zu TC=%u HOPLIMIT=%u FLOWLBL=%u , + ntohs(ih-payload_len) + sizeof(struct ipv6hdr), +- (ntohl(*(__be32 *)ih) 0x0ff0) 20, ++ (ntohl(__get_unaligned_cpu32((__be32 *)ih)) 0x0ff0) 20, + ih-hop_limit, +- (ntohl(*(__be32 *)ih) 0x000f)); ++ (ntohl(__get_unaligned_cpu32((__be32 *)ih)) 0x000f)); Surely that should be get_unaligned_be32()? -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx
On Tue, 2012-04-24 at 00:51 +0200, Michael Markstaller wrote: (I remember the IPv6-day last year, it was funny, even Google failed 30-50%..) That's an... interesting assertion that I've not heard before. Google's own analysis was significantly different. They said: We carried about 65% more IPv6 traffic than usual, saw no significant issues and did not have to disable IPv6 access for any networks or services. And on the surface, the first global test of IPv6 passed without incident. http://googleblog.blogspot.co.uk/2011/06/world-ipv6-day-begins-24-hours-from-now.html Do you expect any DSL user or Soho-Admin which doesn't even understand what an (IPv4) Subnet-mask is to understand that.. Of course not. That's why we're working on stuff like PD so that it just gets delegated by the ISP and all works automatically. a) It's a big security risk at first as noone really knows whats going on with IPv6 (at least on customer/user-side!) With respect, that's complete crap. The security implications are exactly the same with IPv6 as with Legacy IP. By *default* for the home user, you want a connection-tracking firewall that allows outbound-only connections. Some people are naïve enough to think that NAT gives you some kind of security. That's complete crap too. With ALGs automatically opening up return paths, and with uPnP allowing you to open them willy-nilly, allowing an inbound connection when you're behind NAT isn't *that* much harder than just calling listen(). For Legacy IP, a decent connection-tracking firewall is perfectly sufficient and arguably *better* than the false security of NAT. For IPv6 it's just the same. So the first thing before even considering it, is the Firewall on the router (here: OpenWRT) should be at least as closed as for IPv4 with NAT by default. Is it? I *think* it is, but I'm not sure. I vaguely remember having to turn the poxy thing off in order to get inbound connections working properly. That beams the Internet back to 1990, where you just trusted that the others won't do no harm anyway, the only current protection is IMHO that noone knows, how to exploit it.. No, this is also absolutely wrong. In 1990, servers and protocols weren't really designed to cope with a malicious network. There was no SSL. We used telnet, not SSH. And you could crash most boxes by sending fragmented packets that added up to more than 64KiB. In 1990, a firewall might have actually made *sense*. These days, a huge proportion of devices are mobile (phones, laptops), and will connect to arbitrary wireless networks when they're out and about. They may well get an address which isn't firewalled from the outside world (even if it has NAT, it probably still allows some incoming connections), and which almost *certainly* isn't firewalled from all the other untrusted machines on the same network. If those devices are *really* stuck in the 1990s in every other respect, and are only relying on a firewall as a band-aid to let them survive in the 21st century, as you suggest, they they have already lost the game. Thankfully, that just isn't the case. So no, you are absolutely wrong to suggest that *if* we didn't have a firewall enabled by default, that beams the Internet back to 1990. Not that it's relevant anyway, because we *should* (and do?) have a firewall enabled by default. It's a stupid band-aid to work around broken software, and should never really be necessary in an ideal world — but it's a fact of life that people expect it and in some rare cases, if they're really stupid, intentionally rely on it. b) As you mentioned in later posts, it's a pain mixed with more pain, 6to4, 6rd, causes timeouts, problems, troubles (how do I teach that my 6 Cisco Border-Routers? oh well I could buy new ones with 8x RAM etc..)- which end-user wants them and - who pays for? Noone.. I'm not quite sure if you're making a serious point here or just wittering. Yes, 6to4 is a bad way to provide IPv6 connectivity. So is RFC1149. Your point? I've been running IPv6 for years, and I still see *more* problems with Legacy IP, for example morons filtering ICMP and breaking path MTU discovery, than I ever do with IPv6. And often, IPv6 has allowed things to keep working while Legacy IP is failing for some reason. I strongly suspect that 8x RAM on the border routers is an exaggeration. Do you have a reference for that figure? To find some conclusion at least for myself, as soon as deploying IPv6 on End-Users is painless *and at least as secure as v4 with NAT* I'd think about to enable it - and happy to work on. As long as we have that connection-tracking firewall, it *is* at least as secure as Legacy IP. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx
On 12-04-23 06:51 PM, Michael Markstaller wrote: Agreed but lets get realisitic, my objectives (home, office customers) are: 1) security 2) it works 3) technically perfect You forgot: 4) sustainable Do you have children? I suspect you don't. Your lack of forward/future thinking indicates that. It's amazing how one's perspective of the future changes when one starts thinking about the future of their children rather than just their own present day happiness. Likely you don't think we should be exploring alternative energies either, right? I mean why bother? Gasoline is still flowing out of the pumps today right? v6 only meets #3.. and #4, whereas IPv4 doesn't meet #4. a) It's a big security risk at first as noone really knows whats going on with IPv6 (at least on customer/user-side!) It's no more of a security risk that IPv4 is. Both are network protocols that carry traffic to one's front-door so one ought to make sure they have a good door lock. b. signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx
On Tue, 2012-04-24 at 07:04 -0400, Brian J. Murrell wrote: Do you have children? I suspect you don't. Your lack of forward/future thinking indicates that. It's amazing how one's perspective of the future changes when one starts thinking about the future of their children rather than just their own present day happiness. It's not even *forward* thinking. It's just plain *thinking* that's lacking. Legacy IP addresses are running out *now*. The last blocks have been given out to the RIRs. You might be able to connect a *client* in a half-arsed fashion using NAT, and pretend that it's good enough. Millions already do, and they try to paper over the various problems that NAT causes — with a reasonable amount of success, even. But what do you do about servers, and all kinds of other machines that need to be accessible from the outside? -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx
Le 24/04/2012 10:41, David Woodhouse a écrit : On Tue, 2012-04-24 at 00:51 +0200, Michael Markstaller wrote: a) It's a big security risk at first as noone really knows whats going on with IPv6 (at least on customer/user-side!) With respect, that's complete crap. The security implications are exactly the same with IPv6 as with Legacy IP. By *default* for the home user, you want a connection-tracking firewall that allows outbound-only connections. With respect too, allow me to throw my 2 cents on this specific point. It seems you are still considering IPv6 as a protocol that will allow you to communicate from one human controlled device to another human controlled device (for a large definition of human controlled device: web sites, routers, ...). But the target of IPv6 is machine-to-machine communication. The human factor is limited to the high end spectrum of IPv6 use - i.e. most situations where we're using IPv4. Of course, personnal setups are not really an issue here, because you'll not be a very interesting target. But companies, with more and more IP devices, will have some difficulties to cope with the security issues that will necessarily arise. Consider this - not that far fetched - setup: * 10,000 IPv6-addressable light bulbs, each of them controlled by a specialized SoC ; of course, you access the device using a wave-based connection (probably 802.15.4 or a ZigBee-based protocol in this case). Each batch of 1000 light bulb comes from a different vendor. That means you have at least 10 different light bulb vendors, each one with their own weaknesses. * each light bulb runs a simple RT OS, and provide telnet access (because ssh is just too heavy for light bulbs). If you have any security issue on any one of the 100 light bulb vendor then you put your network infrastructure at risk. When I say that this is not far fetched, I really mean it. ZigBee is already avalaible on SoCs [1], and those SoCs are cheaper and cheaper. A day will come where it will be of interest to use these SoCs to provide connectivity on devices you don't even imagine yet (coffee machines, light bulbs, emergency panels, alarm captors... name it, put a SoC on it, and I can assure you that you'll find some commercial interest in doing so). Theory makes IPv6 attractive. But - as everything - the devil is in the details. Regarding IPv6, our first reflexion tells us hey, that will resolve an issue! good thing!. Problems are that many more will be created, and we tend to forgot those. We have a duty to challenge our assumptions: what looks better doesn't mean it's better. As of today, IPv6 looks better, but there are tons of issues to resolve before we can put it on production. Remember that the first IPv6 RFC is 14 years old. From 1998 to today, most RFC dealt with resolving protocol issues that certainly makes IPv6 better than IPv4 but that didn't exist in IPv4 - and since IPv4 works, why one would change? (I'm hearing a comment from the back of the room: IPv4 public address space is full; well, not exactly: public IPv4 addresses have been allocated by IANA to regional registrars. These registrars are still selling IPv4 addresses to their customers - and these customers (mostly ISP) also have a pool of still unallocated addresses - not to mention that some organizations are making big bucks by reselling unused IPs. There is no evidence that a pure B2B or B2C market will deplete the IPv4 address space any time soon. The only problem with the IPv4 address space is that it's too small for M2M communication. Some people are naïve enough to think that NAT gives you some kind of security. That's complete crap too. Of course it does. Even if it's not the primary goal of NAT, it isolates your network from the outside - not because you want to isolate it, but because you cannot affort to spend hundreds of public IPv4 on your corporate network. Security is not tied to NAT but still comes as a by-product of NAT. The fact that you can punch through is what makes NATing insufficient - but one things remain: from the outside, you can't know what are the machine inside unless you enter. That's the difference between being naked in your bathroom and being naked in a public area. Sure, being naked in your bathroom doesn't mean that nobody sees you - but to do so one must at least have a direct view on your bathroom. You may not agree with me, but I believe that hiding information from a potential threat is better that providing these information. The reason why I believe this is quite simple: unless you can assure me that there is no bug on a specific platform, I cannot be sure that noone will find any entry point to gain unauthorized access to this platform. If you can prove me that the platform is 100% secure, then NATing the platform doesn't make much sense if I can give it a public address. This is a case of privacy helps security (a.k.a. security by obscurity) that works (*). Unless you take control of one of
Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx
Would it be too much to ask for those expending time on this debate, to expend a little extra time doing some code review and testing this patch? Or, like while the flames are being composed, merely sending data through it? This particular patch improves ipv4 by over 10% especially when used with the sfq and sfqred qdiscs, fixes encapsulation for ipsec (both ipv4 and ipv6), and yes, more than doubles ipv6 performance on the ag71xx. Although simple in outline, it is pretty invasive into core bits of the kernel. I wish it wasn't, but the alternatives (have the driver rebuffer misaligned packets) were far worse for performance, and the final patch isn't all that big. I agree with felix's suggestion to not let __packed leak out of the kernel headers, and will respin the patch for that. I'm dubious that the check alignment and branch is actually all that useful in the ipv6 checksum code, too, on an arch with a small cache. And I'm still trying to track down the last causes of traps in the routing path, and several other ipv6 and ipv4 related bugs. I'm pretty sure that the traps in the routing path have caused many a tcp reset for me over the last year, under load. http://www.bufferbloat.net/projects/cerowrt/issues/371 http://www.bufferbloat.net/projects/cerowrt/issues http://www.bufferbloat.net/projects/cerowrt/issues/360 -- Dave Täht SKYPE: davetaht US Tel: 1-239-829-5608 http://www.bufferbloat.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx
Hi, On Tue, Apr 24, 2012 at 03:23:50PM +0200, Emmanuel Deloget wrote: There is no evidence that a pure B2B or B2C market will deplete the IPv4 address space any time soon. The only problem with the IPv4 address space is that it's too small for M2M communication. Asia-PAC has *already* run out of IPv4 addresses at the RIR (APNIC) in May 2011, and the first Telcos are *already* not giving their customers IPv4 addresses anymore. RIPE land (Europe and near East) will run out approximately in August, and the first large-scale carriers are already buying and deploying carrier-grade NAT44 boxes to work around IPv4 shortage. I'm perfectly fine with people not liking IPv6 for a number of reasons (I have my own list), but this isn't going to change the numbers. 7 billion humans on earth, 4 billion IPv4 addresses - whatever we do, it will just delay the inevitable (rearranging deck chairs on the titanic). gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpHSrElN8MPL.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx
Hi, On Mon, Apr 23, 2012 at 01:49:18AM +0200, Michael Markstaller wrote: Appreciate your work really but just my 5ct: noone needs IPv6 if not in search for troubles or many new (security)-problems. Welcome to the 21st century. There are ISPs in Asia today(!) that *will* *not* give you an IPv4 address, because they have none left. I love the --disable-ipv6 switch, please keep it working without this experiment, I guess there are many other fields to work on - with more relationship to real-life :o IPv6 is most relevant to real-life. Many of the problems we see in IPv6 deployments are caused exactly by this attitude - instead of *using* it and fixing the problems that are still left, disabling it and hoping that it won't be needed before personal retirement. This won't get any of the issues fixed, and one day you'll find yourself in need of IPv6, and the problems are still there. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpGLg8CjygRJ.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, though really OT, its a really important point for a Router-Distro as which I love OpenWRT; so I'd want to explain my point. And I also read the RIPE-lists where I often have to swallow *not* to respond to all those IPv6-hurrays which arent present in real world IMHO.. First of all, don't get me wrong, I'm technically not against IPv6, we're even offering it for customers (without any extra-price on top) it's just a fact that 0,000% ever asked for (or would pay a cent more for having it), because 100% are running v4.. Am 23.04.2012 11:26, schrieb Gert Doering: There are ISPs in Asia today(!) that *will* *not* give you an IPv4 address, because they have none left. Ok, but I have over 10 sites far east with IPv4 running.. not representative/much but well, it works right herenow. And I'm sure they have some measures to reach 99% of the Internet on this planet through IPv4.. (I remember the IPv6-day last year, it was funny, even Google failed 30-50%..) OTOH, none of my upstreams gives me native IPv6, only tunnel-crap at best (I won't name them, AS42283 for anyone who could Google/read BGP..) So give me one reason to change Upstream, make me 2 weeks of work and maybe pay more, just to be able to participate in this big experiment. IPv6 is most relevant to real-life. I came along without so far ;) Though, again, I could have it running, just don't want as I see no need and many risks/problems.. Many of the problems we see in IPv6 deployments are caused exactly by this attitude Agreed but lets get realisitic, my objectives (home, office customers) are: 1) security 2) it works 3) technically perfect v6 only meets #3.. Do you expect any DSL user or Soho-Admin which doesn't even understand what an (IPv4) Subnet-mask is to understand that.. a) It's a big security risk at first as noone really knows whats going on with IPv6 (at least on customer/user-side!) So the first thing before even considering it, is the Firewall on the router (here: OpenWRT) should be at least as closed as for IPv4 with NAT by default. Is it? Or whats happens if John Doe gets assigned a /64 or John Does Company a /48? Anyone on this planet could Airplay in her/his home, funny :p They are at first widely open, with current OS's having IPv6 happily enabled by default. Thats IMHO a real problem.. I spend more time telling my customers what this really means than why they need v6 sometime in future.. That beams the Internet back to 1990, where you just trusted that the others won't do no harm anyway, the only current protection is IMHO that noone knows, how to exploit it.. b) As you mentioned in later posts, it's a pain mixed with more pain, 6to4, 6rd, causes timeouts, problems, troubles (how do I teach that my 6 Cisco Border-Routers? oh well I could buy new ones with 8x RAM etc..)- which end-user wants them and - who pays for? Noone.. To find some conclusion at least for myself, as soon as deploying IPv6 on End-Users is painless *and at least as secure as v4 with NAT* I'd think about to enable it - and happy to work on. But really, currently I dont see this on the horizon. Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+V3O0ACgkQaWRHV2kMuAJo8wCfW8NxeKWuO1TLf+uCcMX9M0WV It4AoKaSiswc9vLWuQaGbanOWpojq7Bg =FrSy -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx
On Sun, Apr 22, 2012 at 2:48 PM, Dave Täht dave.t...@bufferbloat.net wrote: This updates the existing unaligned_access_hacks patch to reduce unalignment traps to nearly zero for ipv4 and ipv6, in the normal path, in encapsulation, for native apps, and in the qdiscs. While I have tested these patches for several days now, I have not tested them in the default openwrt 'bridged' environment, and they could use more testing as well as a better before/after comparison for ipv4 and ipv6 performance vs a vs wireless. Certainly they won big on ipv6... If you prefer patches free of being mangled by email, see: http://huchra.bufferbloat.net/~d/for_openwrt/ -- Dave Täht SKYPE: davetaht US Tel: 1-239-829-5608 http://www.bufferbloat.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx
On Mon, 2012-04-23 at 02:22 +0200, Michael Markstaller wrote: Am 23.04.2012 01:52, schrieb Dave Taht: It should keep working with the --disable-ipv6 switch. That sounds good ;) Again: I appreciate your work from a technical point of view, also understand this might be good at some point in (far) future but I'm struggling more to get a stableperformant AP with 802.11n/IPv4 right now ;) I know this is OT, so please take this just as my 5ct.. Have you just fallen through a timewarp from some time in the 20th century? Here in the 21st century, Legacy IP addresses are running out. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] Comprehensive ipv4 and ipv6 unaligned access patch for ar71xx
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Here in the 21st century, Legacy IP addresses are running out. Really, where ? :p This story is told for 10yrs now.. And if, lets get get back some /8 from someone using them for 500 hosts instead of NAT and we're off for pretty some time.. Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+UpXEACgkQaWRHV2kMuAIq5wCdFuj+d+WvAdPDA71H3SzOKe9y aOcAniEc/0u6N8n0U2Xg+njTHtvtBfNF =Nk8t -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
