Re: Alignment issues with freescale FEC driver

Hi David, On 09/23/2016 07:43 PM, David Miller wrote: > From: Eric Nelson > Date: Fri, 23 Sep 2016 10:33:29 -0700 > >> Since the hardware requires longword alignment for its' DMA transfers, >> aligning the IP header will require a memcpy, right? > > I wish hardware designers didn't do this. >

RE: Alignment issues with freescale FEC driver

.com; linux-arm- > ker...@lists.infradead.org > Subject: Re: Alignment issues with freescale FEC driver > > From: Eric Nelson > Date: Fri, 23 Sep 2016 11:35:17 -0700 > > > From the i.MX6DQ reference manual, bit 7 of ENET_RACC says this: > > > > "RX FIFO Shift-

Re: Alignment issues with freescale FEC driver

From: Eric Nelson Date: Fri, 23 Sep 2016 11:35:17 -0700 > From the i.MX6DQ reference manual, bit 7 of ENET_RACC says this: > > "RX FIFO Shift-16 > > When this field is set, the actual frame data starts at bit 16 of the first > word read from the RX FIFO aligning the Ethernet payload on a > 32-b

Re: Alignment issues with freescale FEC driver

From: Eric Nelson Date: Fri, 23 Sep 2016 10:33:29 -0700 > Since the hardware requires longword alignment for its' DMA transfers, > aligning the IP header will require a memcpy, right? I wish hardware designers didn't do this. There is no conflict between DMA alignment and properly offseting the

Re: Alignment issues with freescale FEC driver

Hello Russell, On Fri, Sep 23, 2016 at 07:37:25PM +0100, Russell King - ARM Linux wrote: > On Fri, Sep 23, 2016 at 11:26:18AM -0700, Eric Nelson wrote: > > So the question is: should we just live with this and acknowledge a > > performance penalty of bad alignment or do something about it? > > We

Re: Alignment issues with freescale FEC driver

Thanks Russell, On 09/23/2016 11:37 AM, Russell King - ARM Linux wrote: > On Fri, Sep 23, 2016 at 11:26:18AM -0700, Eric Nelson wrote: >> So the question is: should we just live with this and acknowledge a >> performance penalty of bad alignment or do something about it? > > Well, I've no interes

Re: Alignment issues with freescale FEC driver

Thanks Russell, On 09/23/2016 11:30 AM, Russell King - ARM Linux wrote: > On Fri, Sep 23, 2016 at 08:13:01PM +0200, Andrew Lunn wrote: >>> Since the hardware requires longword alignment for its' DMA transfers, >>> aligning the IP header will require a memcpy, right? >> >> The vf610 FEC has an SHIF

Re: Alignment issues with freescale FEC driver

On Fri, Sep 23, 2016 at 11:26:18AM -0700, Eric Nelson wrote: > So the question is: should we just live with this and acknowledge a > performance penalty of bad alignment or do something about it? Well, I've no interest in trying to do anything with the FEC driver anymore, as I'll just generate ano

Re: Alignment issues with freescale FEC driver

On Fri, Sep 23, 2016 at 08:13:01PM +0200, Andrew Lunn wrote: > > Since the hardware requires longword alignment for its' DMA transfers, > > aligning the IP header will require a memcpy, right? > > The vf610 FEC has an SHIFT16 bit in register ENETx_TACC, which inserts > two padding bits on transmit

Re: Alignment issues with freescale FEC driver

Thanks Andrew. On 09/23/2016 11:13 AM, Andrew Lunn wrote: >> Since the hardware requires longword alignment for its' DMA transfers, >> aligning the IP header will require a memcpy, right? > > The vf610 FEC has an SHIFT16 bit in register ENETx_TACC, which inserts > two padding bits on transmit. EN

Re: Alignment issues with freescale FEC driver

Thanks Russell, On 09/23/2016 10:37 AM, Russell King - ARM Linux wrote: > On Fri, Sep 23, 2016 at 10:19:50AM -0700, Eric Nelson wrote: >> Oddly, it does prevent the vast majority (90%+) of the alignment errors. >> >> I believe this is because the compiler is generating an ldm instruction >> when t

Re: Alignment issues with freescale FEC driver

> Since the hardware requires longword alignment for its' DMA transfers, > aligning the IP header will require a memcpy, right? The vf610 FEC has an SHIFT16 bit in register ENETx_TACC, which inserts two padding bits on transmit. ENETx_RACC has the same. What about your hardware? Andrew

Re: Alignment issues with freescale FEC driver

On Fri, Sep 23, 2016 at 10:19:50AM -0700, Eric Nelson wrote: > Oddly, it does prevent the vast majority (90%+) of the alignment errors. > > I believe this is because the compiler is generating an ldm instruction > when the ntohl() call is used, but I'm stumped about why these aren't > generating f

Re: Alignment issues with freescale FEC driver

Hi Eric, On 09/23/2016 10:19 AM, Eric Nelson wrote: > Thanks Eric, > > On 09/23/2016 09:54 AM, Eric Dumazet wrote: >> On Fri, Sep 23, 2016 at 9:43 AM, Eric Nelson wrote: >>> >>> Hello all, >>> >>> We're seeing alignment issues from the ethernet stack on an i.MX6UL board: >>> >>> > > > >>> >>>

Re: Alignment issues with freescale FEC driver

Thanks Eric, On 09/23/2016 09:54 AM, Eric Dumazet wrote: > On Fri, Sep 23, 2016 at 9:43 AM, Eric Nelson wrote: >> >> Hello all, >> >> We're seeing alignment issues from the ethernet stack on an i.MX6UL board: >> >> >> >> - id = ntohl(*(__be32 *)&iph->id); >> - flush = (u16)((ntohl(*(__be32 *)i

Re: Alignment issues with freescale FEC driver

On Fri, Sep 23, 2016 at 9:43 AM, Eric Nelson wrote: > > Hello all, > > We're seeing alignment issues from the ethernet stack on an i.MX6UL board: > > root@mx6ul:~# cat /proc/cpu/alignment > User: 0 > System: 470010 (inet_gro_receive+0x104/0x278) > > This seems to be related to the ip header alignm

Alignment issues with freescale FEC driver

Hello all, We're seeing alignment issues from the ethernet stack on an i.MX6UL board: root@mx6ul:~# cat /proc/cpu/alignment User: 0 System: 470010 (inet_gro_receive+0x104/0x278) This seems to be related to the ip header alignment, and there was much discussion in mailing list threads [1] and [2]