> "David" == David S Miller <[EMAIL PROTECTED]> writes:
David> I think this is an Acenic specific issue. The second processor
David> on the Acenic board is only there to work around bugs in their
David> DMA controller.
It wasn't put there for that reason. It was intended for better work
;-)
Jeff Garzik writes:
> And in another message, On Mon, 12 Feb 2001, David S. Miller wrote:
> > 3) The acenic/gbit performance anomalies have been cured
> >by reverting the PCI mem_inval tweaks.
>
>
> Just to be clear, acenic should or should not use MWI?
>
> And can a general rule b
> "Petr" == Petr Vandrovec <[EMAIL PROTECTED]> writes:
Petr> On 14 Feb 01 at 16:35, Jes Sorensen wrote:
>> What else is sending out 802.3 frames these days? I really don't
>> care about IPX when it comes to performance.
>>
>> I am just advocating that we optimize for the common case which i
On Tue, 13 Feb 2001, Ion Badulescu wrote:
> On Tue, 13 Feb 2001 12:29:16 -0800, Ion Badulescu <[EMAIL PROTECTED]>
>wrote:
> > On Tue, 13 Feb 2001 07:06:44 -0600 (CST), Jeff Garzik
><[EMAIL PROTECTED]> wrote:
> >
> >> On 12 Feb 2001, Jes Sorensen wrote:
> >>> In fact one has to look out for t
On 14 Feb 01 at 16:35, Jes Sorensen wrote:
> > "Donald" == Donald Becker <[EMAIL PROTECTED]> writes:
> Donald> On 12 Feb 2001, Jes Sorensen wrote:
> Donald> ??? - It's not just IPX hosts that send 802.3 headers. -
> Donald> While a good initial value might depend on the architecture,
> Dona
> "Jeff" == Jeff Garzik <[EMAIL PROTECTED]> writes:
Jeff> On 12 Feb 2001, Jes Sorensen wrote:
>> 3) The acenic/gbit performance anomalies have been cured by
>> reverting the PCI mem_inval tweaks.
Jeff> Just to be clear, acenic should or should not use MWI?
Jeff> And can a general rule be ap
> "Donald" == Donald Becker <[EMAIL PROTECTED]> writes:
Donald> On 12 Feb 2001, Jes Sorensen wrote:
>> In this case it just results in a performance degradation for 99%
>> of the usage. What about making the change so it is optimized away
>> unless IPX is enabled?
Donald> ??? - It's not jus
On Wed, 14 Feb 2001, Alan Cox wrote:
> > The way I understand it, IA64 and Alpha cope with it, but at the expense
> > of taking an exception for each packet -- so it's not worth it.
>
> You want to copy_checksum the frame on these platforms,
That's what we're doing...
> or better yet use
> a
> The way I understand it, IA64 and Alpha cope with it, but at the expense
> of taking an exception for each packet -- so it's not worth it.
You want to copy_checksum the frame on these platforms, or better yet use
a decent network card that can start the frame on odd word alignment. You need
ei
On Wed, 14 Feb 2001, Jeff Garzik wrote:
> On Wed, 14 Feb 2001, Alan Cox wrote:
> > It does. It does so on IA64 now as well. The only architecture which has troubles
> > with alignment on IP frames now is ARM2
>
> So the IA64-specific PKT_CAN_COPY code in starfire can go away
> completely? Jes,
On Wed, 14 Feb 2001, Alan Cox wrote:
> > There was not a bug in the driver. The bug was/is in the protocol handling
> > code. The protocol handling code *must* be able to handle unaligned IP
> > headers.
> It does. It does so on IA64 now as well. The only architecture which has troubles
> with
> There was not a bug in the driver. The bug was/is in the protocol handling
> code. The protocol handling code *must* be able to handle unaligned IP
> headers.
It does. It does so on IA64 now as well. The only architecture which has troubles
with alignment on IP frames now is ARM2
-
To unsubs
On 12 Feb 2001, Jes Sorensen wrote:
> > "Donald" == Donald Becker <[EMAIL PROTECTED]> writes:
>
> Donald> On 9 Feb 2001, Jes Sorensen wrote:
> >> The ia64 kernel has gotten mis aligned load support, but it's slow
> >> as a dog so we really want to copy the packet every time anyway
> >> when
On Tue, 13 Feb 2001 12:29:16 -0800, Ion Badulescu <[EMAIL PROTECTED]> wrote:
> On Tue, 13 Feb 2001 07:06:44 -0600 (CST), Jeff Garzik
><[EMAIL PROTECTED]> wrote:
>
>> On 12 Feb 2001, Jes Sorensen wrote:
>>> In fact one has to look out for this and disable the feature in some
>>> cases. On the ace
On 12 Feb 2001, Jes Sorensen wrote:
> Ion> Yes, but I'd rather let people turn off the always-copy behavior
> Ion> by simply changing rx_copybreak. The unused code is not really
> Ion> that much of a deal, it's only a few lines.
>
> However, it is in the hot path code where it hurts the most.
I
On Tue, 13 Feb 2001 07:06:44 -0600 (CST), Jeff Garzik
<[EMAIL PROTECTED]> wrote:
> On 12 Feb 2001, Jes Sorensen wrote:
>> In fact one has to look out for this and disable the feature in some
>> cases. On the acenic not disabling Memory Write and Invalidate costs
>> ~20% on performance on some sy
On 12 Feb 2001, Jes Sorensen wrote:
> > "Gérard" == Gérard Roudier <[EMAIL PROTECTED]> writes:
> Gérard> In PCI, it is the Memory Write and Invalidate PCI transaction
> Gérard> that is intended to allow core-logics to optimize DMA this
> Gérard> way. For normal Memory Write PCI transactions or
> "Gérard" == Gérard Roudier <[EMAIL PROTECTED]> writes:
Gérard> On Fri, 9 Feb 2001, Alan Cox wrote:
>> DMA to main memory normally invalidates those lines in the CPU
>> cache rather than the cache snooping and updating its view of them.
Gérard> In PCI, it is the Memory Write and Invalidate
> "Ion" == Ion Badulescu <[EMAIL PROTECTED]> writes:
Ion> On 9 Feb 2001, Jes Sorensen wrote:
>> Inefficient, my patch will make the unused code path disappear
>> during compilation, what you suggest results in an extra branch and
>> unused code.
Ion> Yes, but I'd rather let people turn off
> "Donald" == Donald Becker <[EMAIL PROTECTED]> writes:
Donald> On 9 Feb 2001, Jes Sorensen wrote:
>> The ia64 kernel has gotten mis aligned load support, but it's slow
>> as a dog so we really want to copy the packet every time anyway
>> when the header is not aligned. If people send out 802
Hi Jes,
I read through your acenic driver and noticed that you replaced
spinlocks with bitops.
Is that a good idea? I always avoid bitops and replace them with
spinlocks:
* On uniprocessor they are obviously slower.
* on SMP i386 spin_lock() / spin_unlock() is faster than
test_and_set_bit()/cle
On Fri, 9 Feb 2001, Alan Cox wrote:
> > > For non routing paths its virtually free because the DMA forced the lines
> > > from cache anyway.
> >
> > Are you actually sure about this? I thought DMA from PCI devices reached
> > the main memory without polluting the L2 cache. Otherwise any larg
> > For non routing paths its virtually free because the DMA forced the lines
> > from cache anyway.
>
> Are you actually sure about this? I thought DMA from PCI devices reached
> the main memory without polluting the L2 cache. Otherwise any large DMA
> transfer would kill the cache (think fra
On Fri, 9 Feb 2001, Alan Cox wrote:
> > It's amusing that a full receive copy is added without any concern, in
> > the same discussion where zero-copy transmit is treated as a holy grail!
>
> For non routing paths its virtually free because the DMA forced the lines
> from cache anyway.
Are you
On 9 Feb 2001, Jes Sorensen wrote:
> > "Jeff" == Jeff Garzik <[EMAIL PROTECTED]> writes:
> Jeff> Donald Becker wrote:
> >> On Tue, 16 Jan 2001, Jeff Garzik wrote: > * IA64 support (Jes) Oh,
> >> and this is completely bogus. This isn't a fix, it's a hack that
> >> covers up the real problem.
On 9 Feb 2001, Jes Sorensen wrote:
> Manfred> What about changing the default for rx_copybreak instead?
> Manfred> Set it to 1536 on ia64 and Alpha, 0 for the rest. tulip and
> Manfred> eepro100 use that aproach.
>
> Inefficient, my patch will make the unused code path disappear during
> compil
> "Manfred" == Manfred Spraul <[EMAIL PROTECTED]> writes:
Manfred> Ion Badulescu wrote:
>> > > +#if defined(__ia64__) || defined(__alpha__) > > +#define
>> PKT_SHOULD_COPY(pkt_len) 1 > > +#else > > +#define
>> PKT_SHOULD_COPY(pkt_len) (pkt_len < rx_copybreak) > > +#endif >
>> [snip]
>>
>> I
> "Jeff" == Jeff Garzik <[EMAIL PROTECTED]> writes:
Jeff> Donald Becker wrote:
>> On Tue, 16 Jan 2001, Jeff Garzik wrote: > * IA64 support (Jes) Oh,
>> and this is completely bogus. This isn't a fix, it's a hack that
>> covers up the real problem.
>>
>> The align-copy should *never* be requ
Ion Badulescu wrote:
> ... and use both SET_MODULE_OWNER and STAR_MOD_*_USE_COUNT. It's along the
> lines of what I was thinking -- though I don't think it's very clean.
It's about the best you can do, considering the 'no ifdefs in raw'
axiom.. Better suggestions are certainly welcome.
> And o
On Fri, 9 Feb 2001, Jeff Garzik wrote:
> For 2.2, define SET_MODULE_OWNER to null.
>
> Define STAR_MOD_INC_USE_COUNT and STAR_MOD_DEC_USE_COUNT. For 2.4,
> these are null. For 2.2, these point to MOD_{INC,DEC}_USE_COUNT.
... and use both SET_MODULE_OWNER and STAR_MOD_*_USE_COUNT. It's along t
Ion Badulescu wrote:
> On Fri, 9 Feb 2001, Jeff Garzik wrote:
> > BTW, I would suggest looking at Jes' acenic.c as an example of a 2.4
> > driver that is clean but also [hopefully!] works under 2.2.
>
> The *only* thing I couldn't solve cleanly is the MOD_{INC,DEC}_USE_COUNT
> vs MODULE_SET_OWNER
On Fri, 9 Feb 2001, Jeff Garzik wrote:
> I would prefer that zerocopy code remain out of all official kernels
> until zerocopy itself is in said kernels. It's experimental code that
> simply cannot work in its present form, due to lack of infrastructure in
> the general kernel. And being based
Ion Badulescu wrote:
> On Thu, 8 Feb 2001, Jeff Garzik wrote:
> > The #ifdef ZEROCOPY code you added is a classic example of the kind of
> > code I -remove- from the kernel tree.
>
> It's an issue of maintainer convenience vs. esthetics. And (last but not
> least) it's also about other people's a
> It's amusing that a full receive copy is added without any concern, in
> the same discussion where zero-copy transmit is treated as a holy grail!
For non routing paths its virtually free because the DMA forced the lines
from cache anyway. Basically its a deficiency in the chipset. We don't supp
On Thu, 8 Feb 2001, Donald Becker wrote:
> > Or we can just tell people, "hey, don't use this 64-bit PCI card on a real
> > 64-bit system, it's broken by design"? I don't think that's a good
> > solution either.
>
> This is not a 64 bit PCI issue.
I know. It was just an ironic comment: we h
On Thu, 8 Feb 2001, Ion Badulescu wrote:
> On Thu, 8 Feb 2001, Donald Becker wrote:
>
> > > > The align-copy should *never* be required because the alignment differs
> > > > between DIX and E-II encapsulated packets. The machine shouldn't crash
> > > > because someone sends you a different enca
On Thu, 8 Feb 2001, Ion Badulescu wrote:
> >The MII read code is no longer reliable. I spent twenty minutes at
> >the show, but couldn't figure out the problem. I haven't been able
> >reproduce the problem locally with my 2.2 code and someone older
> >hardware.
>
> Yes, I've no
On Thu, 8 Feb 2001, Donald Becker wrote:
> > > The align-copy should *never* be required because the alignment differs
> > > between DIX and E-II encapsulated packets. The machine shouldn't crash
> > > because someone sends you a different encapsulation type!
>
> This is true for a number of dr
On Thu, 8 Feb 2001, Jeff Garzik wrote:
> Well at least let's do it the Linux Kernel Way(tm): separate out the
> zerocopy stuff such that there are minimal ifdefs in the code... For
> example:
>
> /* add these functions... */
> #ifdef ZEROCOPY
> static inline setup_txrx_rings(
On Thu, 8 Feb 2001, Jeff Garzik wrote:
> > Well, I decided to bite the bullet and port my zerocopy starfire
> > changes to the official tree, properly ifdef'ed. So here it goes,
>
> I would prefer that the zerocopy changes stay in DaveM's external patch
> until they are ready to be merged. Zeroc
On Thu, 8 Feb 2001, Manfred Spraul wrote:
> What about changing the default for rx_copybreak instead?
> Set it to 1536 on ia64 and Alpha, 0 for the rest.
> tulip and eepro100 use that aproach.
That makes a lot of sense, thanks for the suggestion. I'll do so in the
next version.
Ion
--
It i
Ion Badulescu wrote:
>
> On Thu, 8 Feb 2001, Jeff Garzik wrote:
>
> > I would prefer that the zerocopy changes stay in DaveM's external patch
> > until they are ready to be merged.
>
> I would actually prefer to have a single source for all the driver
> versions. The 2.2.x version I sent to Ala
Ion Badulescu wrote:
>
> > > +#if defined(__ia64__) || defined(__alpha__)
> > > +#define PKT_SHOULD_COPY(pkt_len) 1
> > > +#else
> > > +#define PKT_SHOULD_COPY(pkt_len) (pkt_len < rx_copybreak)
> > > +#endif
> >
> [snip]
>
> It's not *required* per se, as far as I know both the Alpha
On Thu, 8 Feb 2001, Jeff Garzik wrote:
> I would prefer that the zerocopy changes stay in DaveM's external patch
> until they are ready to be merged.
I would actually prefer to have a single source for all the driver
versions. The 2.2.x version I sent to Alan later on actually compiles on
2.
Ion Badulescu wrote:
>
> Hi Jeff,
>
> On Wed, 07 Feb 2001 14:57:16 -0500, Jeff Garzik <[EMAIL PROTECTED]> wrote:
>
> > Here's the patch I have, against vanilla 2.4.2-pre1, with the
> > pci_enable_device preferred changes included...
>
> Well, I decided to bite the bullet and port my zerocopy s
Manfred Spraul wrote:
>
> Jeff Garzik wrote:
> >
> > + SET_MODULE_OWNER(dev);
> >
> > irq = pdev->irq;
> >
>
> One question:
> The code copies 'pdev->irq' into 'dev->irq'.
>
> Is that required, who need 'dev->irq'?
>
> > retval = request_irq(dev->irq, &intr_handler, SA_SHIRQ, dev
Hi Jeff,
On Wed, 07 Feb 2001 14:57:16 -0500, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Here's the patch I have, against vanilla 2.4.2-pre1, with the
> pci_enable_device preferred changes included...
Well, I decided to bite the bullet and port my zerocopy starfire
changes to the official tree, pr
Jeff Garzik wrote:
>
> + SET_MODULE_OWNER(dev);
>
> irq = pdev->irq;
>
One question:
The code copies 'pdev->irq' into 'dev->irq'.
Is that required, who need 'dev->irq'?
> retval = request_irq(dev->irq, &intr_handler, SA_SHIRQ, dev->name, dev);
Can't the driver use?
retval = re
[EMAIL PROTECTED] wrote:
>
> > rejected -- ioaddr assigned a value before pci_enable_device is called
>
> Better ?
Here's the patch I have, against vanilla 2.4.2-pre1, with the
pci_enable_device preferred changes included...
--
Jeff Garzik | "You see, in this world there's two kinds of
> rejected -- ioaddr assigned a value before pci_enable_device is called
Better ?
Dave.
--
| Dave Jones.http://www.suse.de/~davej
| SuSE Labs
diff -urN --exclude-from=/home/davej/.exclude linux/drivers/net/starfire.c
linux-dj/drivers/net/starfire.c
--- linux/drivers/net/starfire.c
Hi Alan, Donald,
This driver should call pci_enable_device before reading
pdev->irq.
regards,
Dave.
--
| Dave Jones.http://www.suse.de/~davej
| SuSE Labs
diff -urN --exclude-from=/home/davej/.exclude linux/drivers/net/starfire.c
linux-dj/drivers/net/starfire.c
--- linux/drivers/net
51 matches
Mail list logo
