netdev - Re: [PATCH] fix e100 rx path on ARM (was [PATCH] e100 rx: or s and el bits)

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Wed, 23 May 2007 23:13:29 -0500
From:	Milton Miller <miltonm@....com>
To:	Milton Miller <miltonm@....com>
Cc:	Jeff Garzik <jgarzik@...ox.com>, e1000-devel@...ts.sourceforge.net,
	David Acker <dacker@...net.com>, netdev@...r.kernel.org,
	Jesse Brandeburg <jesse.brandeburg@...el.com>,
	"Kok, Auke" <auke-jan.h.kok@...el.com>,
	Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
	Scott Feldman <sfeldma@...ox.com>,
	John Ronciak <john.ronciak@...el.com>
Subject: Re: [PATCH] fix e100 rx path on ARM (was [PATCH] e100 rx: or s and el bits)

Auke Kok pointed out I had left an unfinished thought this
morning ... well, here's a completion, but I will mostly
think about David's latest proposal.

I think I was debating proposing this, then got side
tracked then hit send.

On May 23, 2007, at 9:02 AM, Milton Miller wrote:
>
>> What if we just fixed the alignment of rfd to make sure it is cache 
>> aligned?  Then we know our syncs will be a single cache flush.
>
> That doesn't help in the coherent dma case; the device can still
> read in between, and we need to handle the !EL size 0 case.
>
> Actually, I thought about it some more after yesterdays note.
> We can set the size !0 after making sure the device sees EL
> (wmb and pci_sync_for_device), as long as we remember this
> buffer used to be size 0 when doing RX clean, and look ahead
> for another complete packet as long as the size was ever 0.
>
> My proposal was just to use "size is still 0" as that flag,
> wasting the space allocated for that skb.
>
> Another aproach is to always allocate a rfd-only packet
> at the beginning of the loop, and inserting th


... inserting this dummy skb before the last successfuly
allocated one, moving the links around.   This has the
benefit of not allocating a 1500+32 byte buffer that we
don't intend to fill, but is a lot more complicated
insert and move skb around when filling.

We now return you to your previously scheduled program.

Now back to thinking about David's proposal, and my thoughts
about how I might do the allocate non-zero size.

milton

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html