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]
Message-Id: <432a3d01f7b2630b5de24686160539fd@bga.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ