On Mon, 2016-02-01 at 16:55 +, David Laight wrote:
> From: Eric Dumazet
> > Sent: 29 January 2016 22:29
> ...
> > On modern intel cpus, this does not matter at all, sure. It took a while
> > before "rep movsb" finally did the right thing.
>
> Unfortunately memcpy_to_io() etc now map to 'rep mo
From: Eric Dumazet
> Sent: 29 January 2016 22:29
...
> On modern intel cpus, this does not matter at all, sure. It took a while
> before "rep movsb" finally did the right thing.
Unfortunately memcpy_to_io() etc now map to 'rep movsb', and that can
only be optimisied for cached addresses.
So copie
On Sun, 2016-01-31 at 14:13 -0800, Tom Herbert wrote:
> Neither is GRE enabled by default in Linux and it is not a typical
> case. So that patch is an optimization for a very narrow use case that
> impacts the core data path for everyone. Please at least consider
> making it configurable.
No idea
On Fri, Jan 29, 2016 at 6:15 PM, Eric Dumazet wrote:
> On Fri, 2016-01-29 at 16:47 -0800, Tom Herbert wrote:
>
>> Hmm, thanks for pointing that out. It looks like this is called by a
>> couple drivers as part of pulling up the data to get alignment. I am
>> actually surprised they are doing this.
On Fri, 2016-01-29 at 16:47 -0800, Tom Herbert wrote:
> Hmm, thanks for pointing that out. It looks like this is called by a
> couple drivers as part of pulling up the data to get alignment. I am
> actually surprised they are doing this. Flow dissector is not the
> cheapest function in the world a
From: Tom Herbert
Date: Fri, 29 Jan 2016 16:47:46 -0800
> Seems like it might be just as well to pull up a fixed number of
> bytes (ixgbe want min of 60 bytes),
This is precisely what we were trying to move away from, please
don't regress back to that.
On Fri, Jan 29, 2016 at 3:58 PM, Sowmini Varadhan
wrote:
> On (01/29/16 15:31), Tom Herbert wrote:
>> But even within flow dissector, to be completely correct, we need to
>> replace all 32-bit accesses with the mempy (flow_label, mpls label,
>> keyid) and be vigilant about new ones coming in. For
On (01/29/16 15:31), Tom Herbert wrote:
> But even within flow dissector, to be completely correct, we need to
> replace all 32-bit accesses with the mempy (flow_label, mpls label,
> keyid) and be vigilant about new ones coming in. For that matter, ..
well, one question that came to my mind when I
On Fri, Jan 29, 2016 at 3:04 PM, Sowmini Varadhan
wrote:
> On (01/29/16 15:00), Tom Herbert wrote:
>
>> The sparc documentation is pretty clear
>> http://docs.oracle.com/cd/E19253-01/816-4854/hwovr-2/index.html, seems
>> like unaligned accesses are not allowed in the architecture.
>
> yes, but loo
On (01/29/16 15:00), Tom Herbert wrote:
> The sparc documentation is pretty clear
> http://docs.oracle.com/cd/E19253-01/816-4854/hwovr-2/index.html, seems
> like unaligned accesses are not allowed in the architecture.
yes, but looks like you can paper over some of this with
memcpy (as was happen
On Fri, Jan 29, 2016 at 1:09 PM, Sowmini Varadhan
wrote:
> On (01/29/16 13:00), Tom Herbert wrote:
>> Doesn't every IP/VXLAN packet contains unaligned headers? Why don't
>> those create alignment issues (like when stack looks at addresses)?
>
> They do.
>
> http://comments.gmane.org/gmane.linux.ne
On Fri, Jan 29, 2016 at 2:28 PM, Eric Dumazet wrote:
> On Fri, 2016-01-29 at 14:08 -0800, Alexander Duyck wrote:
>
>> It also means DMA becomes dramatically slower as it introduces a
>> partial write access for the start of every frame. It is why we had
>> set NET_IP_ALIGN to 0 on x86 since DMA w
On Fri, 2016-01-29 at 14:08 -0800, Alexander Duyck wrote:
> It also means DMA becomes dramatically slower as it introduces a
> partial write access for the start of every frame. It is why we had
> set NET_IP_ALIGN to 0 on x86 since DMA was becoming more expensive
> when unaligned then reading IP
On Fri, Jan 29, 2016 at 1:33 PM, Eric Dumazet wrote:
> On Fri, 2016-01-29 at 13:16 -0800, Alexander Duyck wrote:
>
>> It has to be something recent. I know back when I wrote the code I
>> tested it on a few different architectures and had to add a few bits
>> in __skb_get_poff so that it would re
On Fri, 2016-01-29 at 13:16 -0800, Alexander Duyck wrote:
> It has to be something recent. I know back when I wrote the code I
> tested it on a few different architectures and had to add a few bits
> in __skb_get_poff so that it would read doff as a u8 instead of
> bitfield in a u32.
>
> Looking
On Fri, Jan 29, 2016 at 1:09 PM, Sowmini Varadhan
wrote:
> On (01/29/16 13:00), Tom Herbert wrote:
>> Doesn't every IP/VXLAN packet contains unaligned headers? Why don't
>> those create alignment issues (like when stack looks at addresses)?
>
> They do.
>
> http://comments.gmane.org/gmane.linux.ne
On Fri, Jan 29, 2016 at 12:01 PM, Eric Dumazet wrote:
> On Fri, 2016-01-29 at 14:44 -0500, Sowmini Varadhan wrote:
>> On (01/29/16 11:37), Eric Dumazet wrote:
>> >
>> > I have no idea why reading iph->saddr or iph->daddr would not hit the
>> > problem, but accessing the 32bit ipv6 flow label would
On (01/29/16 13:00), Tom Herbert wrote:
> Doesn't every IP/VXLAN packet contains unaligned headers? Why don't
> those create alignment issues (like when stack looks at addresses)?
They do.
http://comments.gmane.org/gmane.linux.network/370672
some of it was fixed in https://lkml.org/lkml/2015/7/2
On Fri, Jan 29, 2016 at 10:54 AM, Eric Dumazet wrote:
> On Fri, 2016-01-29 at 10:33 -0800, Eric Dumazet wrote:
>> On Fri, 2016-01-29 at 13:06 -0500, Sowmini Varadhan wrote:
>> > There is an unaligned access at __skb_flow_dissect when it calls
>> > ip6_flowlabel() with the call stack
>> >
>> > __
On Fri, 2016-01-29 at 12:01 -0800, Eric Dumazet wrote:
> On Fri, 2016-01-29 at 14:44 -0500, Sowmini Varadhan wrote:
> > On (01/29/16 11:37), Eric Dumazet wrote:
> > >
> > > I have no idea why reading iph->saddr or iph->daddr would not hit the
> > > problem, but accessing the 32bit ipv6 flow label
On Fri, 2016-01-29 at 14:44 -0500, Sowmini Varadhan wrote:
> On (01/29/16 11:37), Eric Dumazet wrote:
> >
> > I have no idea why reading iph->saddr or iph->daddr would not hit the
> > problem, but accessing the 32bit ipv6 flow label would be an issue.
> >
> > Something is fishy.
>
> I was wonder
On (01/29/16 11:37), Eric Dumazet wrote:
>
> I have no idea why reading iph->saddr or iph->daddr would not hit the
> problem, but accessing the 32bit ipv6 flow label would be an issue.
>
> Something is fishy.
I was wondering about this myself. Even on sparc, I only first
ran into the errors for
From: Eric Dumazet
Date: Fri, 29 Jan 2016 11:37:30 -0800
> But really adding unaligned() accesses in flow dissector would slow it
> quite a lot on MIPS and others.
Agreed, the fix definitely belongs in the callers of these interfaces,
which in this case is the driver.
On Fri, 2016-01-29 at 11:08 -0800, David Miller wrote:
> From: Eric Dumazet
> Date: Fri, 29 Jan 2016 10:40:10 -0800
>
> > I would try following ixgbe fix (sorry, totally untested, but you get
> > the idea...)
> >
> > diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> > b/drivers/net/e
On Fri, 2016-01-29 at 11:06 -0800, David Miller wrote:
> From: Eric Dumazet
> Date: Fri, 29 Jan 2016 10:33:48 -0800
>
> > Why ipv6 stack itself does not trigger the issue ?
> >
> > Maybe the driver itself does not properly align IP headers on sparc ?
> >
> > Make sure NET_IP_ALIGN is 2 on your
On (01/29/16 10:54), Eric Dumazet wrote:
> > Why ipv6 stack itself does not trigger the issue ?
> > Maybe the driver itself does not properly align IP headers on sparc ?
> > Make sure NET_IP_ALIGN is 2 on your build.
> > Note that x86 does not care, but a driver should always align Ethernet
> > hea
From: Eric Dumazet
Date: Fri, 29 Jan 2016 10:40:10 -0800
> I would try following ixgbe fix (sorry, totally untested, but you get
> the idea...)
>
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> index c4003a88bbf6..7ba64ed463a6 100
From: Eric Dumazet
Date: Fri, 29 Jan 2016 10:33:48 -0800
> Why ipv6 stack itself does not trigger the issue ?
>
> Maybe the driver itself does not properly align IP headers on sparc ?
>
> Make sure NET_IP_ALIGN is 2 on your build.
>
> Note that x86 does not care, but a driver should always ali
From: Sowmini Varadhan
Date: Fri, 29 Jan 2016 13:06:51 -0500
> @@ -102,6 +102,17 @@ __be32 __skb_flow_get_ports(const struct sk_buff *skb,
> int
> }
> EXPORT_SYMBOL(__skb_flow_get_ports);
>
> +static inline __be32 ip6_flowlabel_align(const u8 *hdr)
> +{
> + union {
> + _
On Fri, 2016-01-29 at 10:33 -0800, Eric Dumazet wrote:
> On Fri, 2016-01-29 at 13:06 -0500, Sowmini Varadhan wrote:
> > There is an unaligned access at __skb_flow_dissect when it calls
> > ip6_flowlabel() with the call stack
> >
> > __skb_flow_dissect+0x2a8/0x87c
> > eth_get_headlen+0x5c/0xaxa
On Fri, 2016-01-29 at 10:33 -0800, Eric Dumazet wrote:
>
> Why ipv6 stack itself does not trigger the issue ?
>
> Maybe the driver itself does not properly align IP headers on sparc ?
>
> Make sure NET_IP_ALIGN is 2 on your build.
>
> Note that x86 does not care, but a driver should always ali
On Fri, 2016-01-29 at 13:06 -0500, Sowmini Varadhan wrote:
> There is an unaligned access at __skb_flow_dissect when it calls
> ip6_flowlabel() with the call stack
>
> __skb_flow_dissect+0x2a8/0x87c
> eth_get_headlen+0x5c/0xaxa4
> ixgbe_clean_rx_irq+0x5cc/0xb20 [ixgbe]
> ixgbe_poll+0x5a4/0
There is an unaligned access at __skb_flow_dissect when it calls
ip6_flowlabel() with the call stack
__skb_flow_dissect+0x2a8/0x87c
eth_get_headlen+0x5c/0xaxa4
ixgbe_clean_rx_irq+0x5cc/0xb20 [ixgbe]
ixgbe_poll+0x5a4/0x760 [ixgbe]
net_rx_action+0x13c/0x354
:
Essentially, ixgbe_pull_
33 matches
Mail list logo
