linux-kernel - Re: Net: ucc_geth ethernet driver optimization space

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <2a27d3730905270336n120f7652yad269858ff456c64@mail.gmail.com>
Date:	Wed, 27 May 2009 18:36:14 +0800
From:	Li Yang <leoli@...escale.com>
To:	Liu Dave-R63238 <DaveLiu@...escale.com>
Cc:	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	linuxppc-dev@...abs.org
Subject: Re: Net: ucc_geth ethernet driver optimization space

On Wed, May 27, 2009 at 1:08 PM, Liu Dave-R63238 <DaveLiu@...escale.com> wrote:
> Guys,
>
> The ucc_geth ethernet driver have dozens of strong sync read/write
> operation, such as in_be32/16/8, out_be32/16/8.
>
> all of them is sync read/write, it is very expensive for performance.
>

Totally agree.  That's one of my concerns right from the beginning.

> For the critical patch, we can remove some unnecessary in_be(x),
> out_be(x) with normal memory operation, and keep some necessary
> memory barrier.
>
> eg: BD access in the interrupt handler and start_xmit.
>
> The BD operation only need the memory barrier between length/buffer
> and status.
>
> struct buffer descriptor {
>        u16 status;
>        u16 length;
>        u32 buffer;
> } __attribute__ ((packed));
>
> struct buffer descriptor *BD;
>
> BD->length = xxxx;
> BD->buffer = yyyy;
> wmb();
> BD->status = zzzz;

The BD can reside either in memory or memory mapped region, which
makes the case more complex.

MMIO accesses need to use IO accessors for the sparse checking.  We
might make use of the __raw_*() accessors, but I'm not sure if it's
suitable for non-PCI buses on powerpc.  And also we need to pay
special attention to the problem described here:
http://lwn.net/Articles/198988/

- Leo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/