[PATCH] [V3] Add non-Virtex5 support for LL TEMAC driver

[John Linn]

> -----Original Message-----
> From: Eric Dumazet [mailto:eric.dumazet at gmail.com]
> Sent: Tuesday, April 06, 2010 11:01 AM
> To: John Linn
> Cc: netdev at vger.kernel.org; linuxppc-dev at ozlabs.org; grant.likely at secretlab.ca;
> jwboyer at linux.vnet.ibm.com; john.williams at petalogix.com; michal.simek at petalogix.com; John Tyner
> Subject: RE: [PATCH] [V3] Add non-Virtex5 support for LL TEMAC driver
> 
> Le mardi 06 avril 2010 à 10:12 -0600, John Linn a écrit :
> > > -----Original Message-----
> > > From: Eric Dumazet [mailto:eric.dumazet at gmail.com]
> > > Sent: Monday, April 05, 2010 3:30 PM
> > > To: John Linn
> > > Cc: netdev at vger.kernel.org; linuxppc-dev at ozlabs.org; grant.likely at secretlab.ca;
> > > jwboyer at linux.vnet.ibm.com; john.williams at petalogix.com; michal.simek at petalogix.com; John Tyner
> > > Subject: Re: [PATCH] [V3] Add non-Virtex5 support for LL TEMAC driver
> > >
> > > Le lundi 05 avril 2010 à 15:11 -0600, John Linn a écrit :
> > > > This patch adds support for using the LL TEMAC Ethernet driver on
> > > > non-Virtex 5 platforms by adding support for accessing the Soft DMA
> > > > registers as if they were memory mapped instead of solely through the
> > > > DCR's (available on the Virtex 5).
> > > >
> > > > The patch also updates the driver so that it runs on the MicroBlaze.
> > > > The changes were tested on the PowerPC 440, PowerPC 405, and the
> > > > MicroBlaze platforms.
> > > >
> > > > Signed-off-by: John Tyner <jtyner at cs.ucr.edu>
> > > > Signed-off-by: John Linn <john.linn at xilinx.com>
> > > >
> > > > ---
> > >
> > > > +/* Align the IP data in the packet on word boundaries as MicroBlaze
> > > > + * needs it.
> > > > + */
> > > > +
> > > >  #define XTE_ALIGN       32
> > > > -#define BUFFER_ALIGN(adr) ((XTE_ALIGN - ((u32) adr)) % XTE_ALIGN)
> > > > +#define BUFFER_ALIGN(adr) ((34 - ((u32) adr)) % XTE_ALIGN)
> > > >
> > >
> > > Very interesting way of doing this, but why such convoluted thing ?
> >
> > This is trying to align for a cache line (32 bytes) before my change.
> >
> > My change was then also making it align the IP data on a word boundary.
> >
> > >
> > > Because of the % 32, this is equivalent to :
> > >
> > > #define BUFFER_ALIGN(adr) ((2 - ((u32) adr)) % XTE_ALIGN)
> > >
> >
> > Yes, but I'm not sure that's clearer IMHO.
> >
> > > But wait, dont we recognise the magic constant NET_IP_ALIGN ?
> >
> > Yes it could be used.  I'm struggling with how to make this all be clearer.
> >
> 
> I am not saying its clearer, I am saying we have a standard way to
> handle this exact problem (aligning rcvs buffer so that IP header is
> aligned)
> 
> There is no need to invent new ones, this makes reviewing of this driver
> more difficult.
> 
> 
> > How about this?
> > #define BUFFER_ALIGN(adr) (((XTE_ALIGN + NET_IP_ALIGN) - ((u32) adr)) % XTE_ALIGN)
> >
> 
> Sorry, I still dont understand why you need XTE_ALIGN + ...
> 
> ((A + B) - C) % A   is equal to (B - C) % A
> 
> Which one is more readable ?

I'm fine with your suggestion.

#define BUFFER_ALIGN(adr) ((2 - ((u32) adr)) % XTE_ALIGN)

> 
> Please take a look at existing and clean code, no magic macro, and we
> can understand the intention.
> 
> find drivers/net | xargs grep -n netdev_alloc_skb_ip_align
> 
> 

Yes I see how it's used, but it only allows you to reserve 2 bytes in the skb with no options.




This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.