Todd wrote:
> While I agree with what's going on right now, the recent purchase of
> Alteon by Nortel (primarily for their switch line, not for the
> NICs) leaves quite a bit of doubt in my mind about the future of the card
> and the openness of the firmware in particular.
Why not raise your conc
> "Todd" == Todd <[EMAIL PROTECTED]> writes:
>> > Jes Sorensen wrote: > > It took me a little while in the
>> beginning to convince Alteon to open > > up and provide docs, but
>> since they saw the light they have been > > extremely helpful and
>> went much further in their openness than I h
> > Jes Sorensen wrote:
> > > It took me a little while in the beginning to convince Alteon to open
> > > up and provide docs, but since they saw the light they have been
> > > extremely helpful and went much further in their openness than I had
> > > ever expected or dared to hope for.
> >
> > A
> Jes Sorensen wrote:
> > It took me a little while in the beginning to convince Alteon to open
> > up and provide docs, but since they saw the light they have been
> > extremely helpful and went much further in their openness than I had
> > ever expected or dared to hope for.
>
> And now it's re
Jes Sorensen wrote:
> It took me a little while in the beginning to convince Alteon to open
> up and provide docs, but since they saw the light they have been
> extremely helpful and went much further in their openness than I had
> ever expected or dared to hope for.
And now it's really showing i
> "Jamie" == Jamie Lokier <[EMAIL PROTECTED]> writes:
Jamie> According to group legend here (I wasn't around but will repeat
Jamie> what I was told), we spent about 1 year trying to get docs on
Jamie> Intel's i960 based gigabit card so we could program it.
Jamie> Eventually we gave up and mov
Alan Cox wrote:
> I've spent over 2 years trying to extract eepro100 server docs out of Intel
> and failed.
[EMAIL PROTECTED] said:
> Sounds familiar :-)
Very familiar. I have a whole development environment for the i960RP
(we use the processor on boards we make) and by looking at pictures
I wa
Alan Cox wrote:
> I've spent over 2 years trying to extract eepro100 server docs out of Intel
> and failed.
Sounds familiar :-)
According to group legend here (I wasn't around but will repeat what I
was told), we spent about 1 year trying to get docs on Intel's i960
based gigabit card so we coul
> > True the i960 based one I didn't think of, however Intel never
> > provided docs for it.
>
> ??? I find this surprising. Email [EMAIL PROTECTED] and ask him if
> they will give them to you. I'm sure they would for Linux.
I've spent over 2 years trying to extract eepro100 server docs out of
> "Jeff" == Jeff V Merkey <[EMAIL PROTECTED]> writes:
Jeff> IPX is a really good LAN protocol (but totally sucks for
Jeff> internet). A full blown NCP server in-kernel that's toughtly
Jeff> coupled to the page cache running over IPX would make flames
Jeff> shoot out of the back of a Linux se
> "Jeff" == Jeff V Merkey <[EMAIL PROTECTED]> writes:
Jeff> Intel Nitro Card - i960 processor on the card. The SMP
Jeff> debugging involved the use of a bus analyser since this card had
Jeff> a piggish memory bus footprint (i960 processors do not have an
Jeff> IO address space, so everything
On Tue, Sep 05, 2000 at 11:25:12AM -0700, Dan Hollis wrote:
> On 5 Sep 2000, Henning P. Schmiedehausen wrote:
> > [EMAIL PROTECTED] (Jeff V. Merkey) writes:
> > >IPX is a really good LAN protocol (but totally sucks for internet). A
> > Jeff, Netware is dead. Please leave it there. IP won. The num
> "Jeff" == Jeff V Merkey <[EMAIL PROTECTED]> writes:
Jeff> Jes Sorensen wrote:
>> True the i960 based one I didn't think of, however Intel never
>> provided docs for it.
Jeff> ??? I find this surprising. Email [EMAIL PROTECTED] and ask
Jeff> him if they will give them to you. I'm sure th
Jes Sorensen wrote:
>
> > "Jeff" == Jeff V Merkey <[EMAIL PROTECTED]> writes:
>
> Jeff> Intel Nitro Card - i960 processor on the card. The SMP
> Jeff> debugging involved the use of a bus analyser since this card had
> Jeff> a piggish memory bus footprint (i960 processors do not have an
>
Dear Stu,
I apologize for bothering you, but how possible would it be to let the
Linux folks get access to the Nitro docs and docs for Intel ethernet
cards in general. There seems to be interest from folks in getting this
to improve Linux support for Intel products.
Any help would be appreciat
On Tue, 5 Sep 2000, Henning P . Schmiedehausen wrote:
> On Tue, Sep 05, 2000 at 11:25:12AM -0700, Dan Hollis wrote:
> > I think you mean IPX is dead. Netware *could* work over TCP or UDP.
> > IP is definitely king. Even micro$haft gave up on NetBEUI.
> Yep, thats' what I meant. Sorry that I was no
On 5 Sep 2000, Henning P. Schmiedehausen wrote:
> [EMAIL PROTECTED] (Jeff V. Merkey) writes:
> >IPX is a really good LAN protocol (but totally sucks for internet). A
> Jeff, Netware is dead. Please leave it there. IP won. The number of
> new Netware Installations (as compared to existing or just
Only Linux makes the lights flash with IPX RIP/SAP. NetWare uses NLSP
routing and has since 1993 for IPX/SPX. I agree if someone is running
NetWare 3 or NetWare 4.1 or earlier there's a lot of RIP/SAP traffic,
but not the NLSP versions -- they do not use RIP/SAP but NLSP.
Jeff
Jes Sorensen wr
> "Jeff" == Jeff V Merkey <[EMAIL PROTECTED]> writes:
Jeff> Only Linux makes the lights flash with IPX RIP/SAP. NetWare
Jeff> uses NLSP routing and has since 1993 for IPX/SPX. I agree if
Jeff> someone is running NetWare 3 or NetWare 4.1 or earlier there's a
Jeff> lot of RIP/SAP traffic, but
NT only uses RIP/SAP.
Jeff
Jes Sorensen wrote:
>
> > "Jeff" == Jeff V Merkey <[EMAIL PROTECTED]> writes:
>
> Jeff> Only Linux makes the lights flash with IPX RIP/SAP. NetWare
> Jeff> uses NLSP routing and has since 1993 for IPX/SPX. I agree if
> Jeff> someone is running NetWare 3 or
On Wed, 6 Sep 2000, Chris Wedgwood wrote:
> [...] The point is that a write() is only used if some sort of
> dynamic data is generated on the fly.
>
> There are exsiting applications out there that use mmap+write
> (caching the maps), it would be nice for the authors of these not to
> h
On Mon, 4 Sep 2000, Jamie Lokier wrote:
> Alan Cox wrote:
> > > It's not faster than card->card DMA, which falls out naturally from my
> > > zero-copy proposal :-)
> >
> > We already support card->card DMA for routing with fastrouting
>
> ..but not for user space proxies which was the above's c
On Mon, 4 Sep 2000, Linus Torvalds wrote:
> On Mon, 4 Sep 2000, Jamie Lokier wrote:
>
> > Linus Torvalds wrote:
> >
> > > Basically any copy <= 4 cache lines is "free" compared to trying to be
> > > clever.
> >
> > We're obviously interested in larger packets than 128 bytes.
>
> "obviously"?
[EMAIL PROTECTED] (Jeff V. Merkey) writes:
>Linus Torvalds wrote:
>>
>>
>>
>> Basically, only TCP and UDP really matter. Decnet, IPX, etc don't really
>> make a big selling point any more.
>>
>>
>Linus,
>IPX is a really good LAN protocol (but totally sucks for internet). A
>full blown N
On Tue, Sep 05, 2000 at 04:35:43AM -0600, Jeff V. Merkey wrote:
>
> IPX is a really good LAN protocol (but totally sucks for internet). A
> full blown NCP server in-kernel that's toughtly coupled to the page
> cache running over IPX would make flames shoot out of the back of a
> Linux server, and
Ingo Molnar wrote:
>
> On Tue, 5 Sep 2000, Jeff V. Merkey wrote:
>
> > The origin of this comment was related to a comparison of the
> > MSM/TSM/CSM layer in NetWare and Linux. I've already said that Alan's
> > code handles fast paths well and from what I've seen is comparable to
> > NetWare.
On Tue, 5 Sep 2000, Jeff V. Merkey wrote:
> The origin of this comment was related to a comparison of the
> MSM/TSM/CSM layer in NetWare and Linux. I've already said that Alan's
> code handles fast paths well and from what I've seen is comparable to
> NetWare. [...]
can we thus take this as a r
You opened your mouth.
:-)
Jeff
Ingo Molnar wrote:
>
> btw., - the maintainers of the 2.4 networking and TCP/IP code are Alexey
> Kuznetsov and David S. Miller - please direct your findings towards them,
> not me :-)
>
> Ingo
-
To unsubscribe from this list: send the line "unsubscr
The origin of this comment was related to a comparison of the
MSM/TSM/CSM layer in NetWare and Linux. I've already said that Alan's
code handles fast paths well and from what I've seen is comparable to
NetWare. The areas I saw where sideband cases and issues of fragment
re-assembly. It
btw., - the maintainers of the 2.4 networking and TCP/IP code are Alexey
Kuznetsov and David S. Miller - please direct your findings towards them,
not me :-)
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Plea
On Tue, 5 Sep 2000, Jeff V. Merkey wrote:
> Alright Ingo, you asked for it. I am going through it now and going
> over ALL my notes. I will catalog ALL of them and post it. Is this
> what you really want?
yes, this would be the best indeed, to get those places fixed. But if you
dont want to spe
Alright Ingo, you asked for it. I am going through it now and going
over ALL my notes. I will catalog ALL of them and post it. Is this
what you really want?
:-)
Jeff
Ingo Molnar wrote:
>
> On Tue, 5 Sep 2000, Jeff V. Merkey wrote:
>
> > > > while (x)
> > > > {
> > > > x = x->next
>
Linus Torvalds wrote:
>
>
>
> Basically, only TCP and UDP really matter. Decnet, IPX, etc don't really
> make a big selling point any more.
>
>
Linus,
IPX is a really good LAN protocol (but totally sucks for internet). A
full blown NCP server in-kernel that's toughtly coupled to the page
On Tue, 5 Sep 2000, Jeff V. Merkey wrote:
> > > while (x)
> > > {
> > > x = x->next
> > > }
> > >
> > > all over the place that increases latency. [...]
> >
> > i challenge you to show one such place in the 2.4.0-test8-pre2 kernel. If
> > it's all over the place and if it increases latency, y
Intel Nitro Card - i960 processor on the card. The SMP debugging
involved the use of a bus analyser since this card had a piggish memory
bus footprint (i960 processors do not have an IO address space, so
everything is memory mapped. The big weakness of early I2O stuff was
that the I960 running
Ingo,
When I have time to do this exercise, I will. I've finished merging
Alan's Code into MANOS (completed last night). Most of the cases I saw
where there were copies were not fast path. It takes some time to go
through all this code you guys have written. It is actually looking
good.
J
Ingo,
I looked through some of the Tux docs and stuff over the weekend. You
are correct, it looks an awful lot like the Topology Support Module
Layer in NetWare, and I agree it provides very similiar semantics. I
won't know how Alan's code stacks up against NetWare until I complete
the port, b
[EMAIL PROTECTED] wrote:
> Few month ago, I gathered precice data and posted it on lk-ml. In our
> experiment, I used four 100Base cards, the Web-Bench gained nearly 5%
> performance by the patch. The CPU load reached over 95%.
>
> I want to show the reference to experiments results, But unfor
On Mon, 4 Sep 2000, Jamie Lokier wrote:
> Linus Torvalds wrote:
>
> > Basically any copy <= 4 cache lines is "free" compared to trying to be
> > clever.
>
> We're obviously interested in larger packets than 128 bytes.
"obviously"?
Take a look at some common traffic. Yes, even in servers.
> "Richard" == Richard Gooch <[EMAIL PROTECTED]> writes:
Richard> I thought you said some of the GigE drivers supported this?
Richard> Or were you just saying that the GigE cards were some of the
Richard> few which supported scatter/gather DMA and IP checksumming?
The latter.
Jes
-
To unsub
Hi,
On Sun, Sep 03, 2000 at 07:29:56PM +0200, Ingo Molnar wrote:
>
> On Sun, 3 Sep 2000, Andi Kleen wrote:
>
> > I did the same for fragment RX some months ago (simple fragment lists
> > that were copy-checksummed to user space). Overall it is probably
> > better to use a kiovec, because that c
Jes Sorensen writes:
> > "Richard" == Richard Gooch <[EMAIL PROTECTED]> writes:
>
> Richard> Andrew Morton writes:
> >> All of them except the 3c905 provide hardware Rx and Tx
> >> checksumming of IP, TCP and UDP headers. No 64 bit addressing
> >> support.
>
> Richard> And does the driver s
> "Ingo" == Ingo Molnar <[EMAIL PROTECTED]> writes:
Ingo> On Mon, 4 Sep 2000 [EMAIL PROTECTED] wrote:
>> The experiment showed the following prefetching could reduce 20-30%
>> of csum_partial_copy_generic() execution time.
Ingo> Please test it and post the numbers. csum_partial_copy_generic
> "Jamie" == Jamie Lokier <[EMAIL PROTECTED]> writes:
Jamie> Nice point! Only valid for TCP & UDP though.
Jamie> When people want _real_ low latency, they don't use TCP or UDP,
Jamie> and they certainly don't put data checksums at the start. They
Jamie> still aim for zero copies. That pas
> "Ingo" == Ingo Molnar <[EMAIL PROTECTED]> writes:
Ingo> On Sun, 3 Sep 2000, Andi Kleen wrote:
>> I did the same for fragment RX some months ago (simple fragment
>> lists that were copy-checksummed to user space). Overall it is
>> probably better to use a kiovec, because that can be more ea
> "Jamie" == Jamie Lokier <[EMAIL PROTECTED]> writes:
Jamie> It's not faster than card->card DMA, which falls out naturally
Jamie> from my zero-copy proposal :-)
Except that many cards and PCI bridges don't work and you lose the
buffering aspect in this case.
Jes
-
To unsubscribe from this
> "Ingo" == Ingo Molnar <[EMAIL PROTECTED]> writes:
Ingo> i believe such zero-copy send should only be allowed for drivers
Ingo> which can guarantee correct checksums. (ie. cards which do
Ingo> Tx-checksums) The other drivers will still copy. I dont think
Ingo> this is a problem - the number
> "Richard" == Richard Gooch <[EMAIL PROTECTED]> writes:
Richard> Andrew Morton writes:
>> All of them except the 3c905 provide hardware Rx and Tx
>> checksumming of IP, TCP and UDP headers. No 64 bit addressing
>> support.
Richard> And does the driver support it? Has anyone benchmarked the
Ingo Molnar writes:
> On Mon, 4 Sep 2000 [EMAIL PROTECTED] wrote:
> > The experiment showed the following prefetching could reduce 20-30% of
> > csum_partial_copy_generic() execution time.
>
> Please test it and post the numbers. csum_partial_copy_generic() already
> does prefetching - the r
Linus Torvalds wrote:
> (The "invalidate on write" is the sane way of doing SMP cache coherency,
> which is probably why. Trying to have shared dirty cache-lines is just
> not a viable option in the end).
With DMA from a device -- "snoop and update" still results in only one
owner of the dirty ca
Alan Cox wrote:
> > struct page of course). Note that it doesn't matter if another thread,
> > and this includes truncate/write in another thread, clobbers the page
> > data. That's just the normal effect of two concurrent writers to the
> > same memory.
>
> Oh it does matter. You might send ou
> > those pages out of cache which isnt so ideal if the CPU wants
> > them. Some of the results are suprisingly counter-intuitive like this
>
> Does it flush the CPU cache? I thought the CPU just snooped the bus and
> updated its cache with new data.
In general no.
> struct page of course).
On Mon, 4 Sep 2000 [EMAIL PROTECTED] wrote:
> The experiment showed the following prefetching could reduce 20-30% of
> csum_partial_copy_generic() execution time.
Please test it and post the numbers. csum_partial_copy_generic() already
does prefetching - the real test would be to check lat_tcp
The experiment showed the following prefetching could reduce 20-30% of
csum_partial_copy_generic() execution time.
This suggests CPU cause heavy cache miss at checksum calclation and it
is also supported by the PMC (performance monitoring counter)
measurements. So I think the following statement i
On Sun, 3 Sep 2000, Lincoln Dale wrote:
>
> many people (myself included) have been experimenting with zerocopy
> infrastructures.
> in my case, i've been working on it as time permits for quite a few months
> now, and am about on my fourth rewrite.
Heh.
> i've found exactly what you state
At 22:53 03/09/00, Linus Torvalds wrote:
> >Ugh. User space DMA gets complicated quickly. The performance question
> >is, perhaps, can you do this without a TLB flush (but with locking the
> >struct page of course). Note that it doesn't matter if another thread,
> >and this includes truncate/wr
In article <[EMAIL PROTECTED]>,
Jamie Lokier <[EMAIL PROTECTED]> wrote:
>Alan Cox wrote:
>> > read/recv block while the NIC DMAs into user space main memory.
>>
>> Thats actually not always a win either. A DMA to user space flushes
>> those pages out of cache which isnt so ideal if the CPU wants
Alan Cox wrote:
> > read/recv block while the NIC DMAs into user space main memory.
>
> Thats actually not always a win either. A DMA to user space flushes
> those pages out of cache which isnt so ideal if the CPU wants
> them. Some of the results are suprisingly counter-intuitive like this
Does
Alan Cox wrote:
> > It's not faster than card->card DMA, which falls out naturally from my
> > zero-copy proposal :-)
>
> We already support card->card DMA for routing with fastrouting
..but not for user space proxies which was the above's context.
Still, the fastrouting proves card->card DMA a
> It's not faster than card->card DMA, which falls out naturally from my
> zero-copy proposal :-)
We already support card->card DMA for routing with fastrouting
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read
> read/recv block while the NIC DMAs into user space main memory.
Thats actually not always a win either. A DMA to user space flushes those pages
out of cache which isnt so ideal if the CPU wants them. Some of the results
are suprisingly counter-intuitive like this
> (Can't DMA earlier because w
On Sun, 3 Sep 2000, Jamie Lokier wrote:
>
> Nice point! Only valid for TCP & UDP though.
Yeah. But "we need oxygen" is only a valid point for carbon-based
life-forms. You might as well argue that oxygen is not avalid criteria for
being livable, because it's only valid for the particular kind
Ingo Molnar wrote:
> > At CERN we had a bunch of applications where this would be a win, data
> > aquisition servers taking data in from on some custom hardware and
> > sending out data over the wire on another card. You never really want
> > to touch data in memory with the CPU but because of the
Linus Torvalds wrote:
> Proof: the data to be sent out is in RAM. In fact, often it is cached
> in the CPU these days. In order to start sending out the packet, the
> smart card has to move all of the data from RAM/cache over the bus to
> the card. It can only start actually sending afte
Andi Kleen wrote:
> On Sun, Sep 03, 2000 at 05:22:44AM +0200, Jamie Lokier wrote:
> > I just thought I'd mention that you can do zero copy TCP in and out
> > *without* any page marking schemes. All you need is a network card with
> > quite a lot of RAM and some intelligence. An Alteon could do i
Alan Cox wrote:
> > I just thought I'd mention that you can do zero copy TCP in and out
> > *without* any page marking schemes. All you need is a network card with
>
> No
>
> > quite a lot of RAM and some intelligence. An Alteon could do it, with
> > extra RAM or an impressively underloaded ne
> i think it's a quality of implementation issue. The csum_copy_generic
> thing is a bug. Allowing incorrect checksums to be sent out would be a
> design bug. I think some RFCs do even forbid the sending of incorrect
> packets?
You are perfectly at liberty to send invalidly checksummed packets. I
Ingo Molnar ([EMAIL PROTECTED]) wrote:
> yep i agree - in this case a receivefile() implementation would be handy
> (we are 100% ready in 2.4 to introduce it - from the pagecache and VFS
> point of view, it's just not there yet), thus you could receivefile() your
> data into a temporary file, a
On Sun, Sep 03, 2000 at 07:42:53PM +0200, Ingo Molnar wrote:
>
> On Sun, 3 Sep 2000, Andi Kleen wrote:
>
> > You can already cause incorrect checksums on the wire just by passing
> > a partly unmapped address (the zero-the-rest exception handler in
> > csum_copy_generic in i386 forgets to add in
Ingo Molnar wrote:
> i believe such zero-copy send should only be allowed for drivers which can
> guarantee correct checksums.
Hmm, I think this shouldn't be tied too closely to TCP. E.g. you can
probably play wonderful ALF tricks with raw sockets.
For TCP/UDP, such a restriction may be useful,
On Sun, 3 Sep 2000, Andi Kleen wrote:
> You can already cause incorrect checksums on the wire just by passing
> a partly unmapped address (the zero-the-rest exception handler in
> csum_copy_generic in i386 forgets to add in the carry)
>
> I do not believe it is a big deal, packets with bad chec
On Sun, Sep 03, 2000 at 07:21:50PM +0200, Ingo Molnar wrote:
>
> On Sun, 3 Sep 2000 [EMAIL PROTECTED] wrote:
>
> > If we go for a Linux-specific solution anyway, maybe one could add
> > another send{,to,msg} flag that makes send*(2)'s buffer access
> > non-atomic. That way, the kernel only needs
On 3 Sep 2000, Jes Sorensen wrote:
> At CERN we had a bunch of applications where this would be a win, data
> aquisition servers taking data in from on some custom hardware and
> sending out data over the wire on another card. You never really want
> to touch data in memory with the CPU but beca
On Sun, 3 Sep 2000, Andi Kleen wrote:
> I did the same for fragment RX some months ago (simple fragment lists
> that were copy-checksummed to user space). Overall it is probably
> better to use a kiovec, because that can be more easily used in nfsd
> and sendfile.
the basic fragment type introd
On Sun, 3 Sep 2000 [EMAIL PROTECTED] wrote:
> If we go for a Linux-specific solution anyway, maybe one could add
> another send{,to,msg} flag that makes send*(2)'s buffer access
> non-atomic. That way, the kernel only needs to make sure the pages
> don't disappear, but there's no need for expens
Andrew Morton writes:
> Jes Sorensen wrote:
> >
> > I only know of a few 100baseT cards that can do it such as the
> > Adaptec Starfire and the 3C905B
> > (though I am not sure what it provides is sufficient).
>
> The 3c905, 3c905B, 3c905C and all 3Com Cardbus NICs will do
> scatter and gather o
> "Andrew" == Andrew Morton <[EMAIL PROTECTED]> writes:
Andrew> Jes Sorensen wrote:
>> I only know of a few 100baseT cards that can do it such as the
>> Adaptec Starfire and the 3C905B (though I am not sure what it
>> provides is sufficient).
Andrew> The 3c905, 3c905B, 3c905C and all 3Com C
Jes Sorensen wrote:
>
> I only know of a few 100baseT cards that can do it such as the
> Adaptec Starfire and the 3C905B
> (though I am not sure what it provides is sufficient).
The 3c905, 3c905B, 3c905C and all 3Com Cardbus NICs will do
scatter and gather of up to 63 fragments per packet with
b
Ingo Molnar wrote:
> On 2 Sep 2000, Jes Sorensen wrote:
> > Besides that you need to do copy-on-write if you want to be able to do
> > zero copy on write() from user space [...]
>
> i agree that this is hard - i'm not sure wether we want to go the pain to
> enable anonymous-buffer write()s do zer
> "Ingo" == Ingo Molnar <[EMAIL PROTECTED]> writes:
Ingo> On 2 Sep 2000, Jes Sorensen wrote:
>> You can't DMA directly from a file cache page unless you have a
>> network card that does scatter/gather DMA and surprise surprise,
>> 80-90% of the cards on the market don't support this. [...]
> "Jeff" == Jeff V Merkey <[EMAIL PROTECTED]> writes:
Jeff> There's been a few cards around since about 1995, but I don't
Jeff> remember all of them. I do remember having to debug SMP code on
Jeff> them though -- yec
I wouldn't be surprised but I would prefer names. Doing SMP aware
> I just thought I'd mention that you can do zero copy TCP in and out
> *without* any page marking schemes. All you need is a network card with
No
> quite a lot of RAM and some intelligence. An Alteon could do it, with
> extra RAM or an impressively underloaded network.
PCI bus latency on rea
On Sun, Sep 03, 2000 at 05:22:44AM +0200, Jamie Lokier wrote:
> I just thought I'd mention that you can do zero copy TCP in and out
> *without* any page marking schemes. All you need is a network card with
> quite a lot of RAM and some intelligence. An Alteon could do it, with
> extra RAM or an
On Sun, Sep 03, 2000 at 10:18:50AM +0200, Ingo Molnar wrote:
>
> On 2 Sep 2000, Jes Sorensen wrote:
>
> > You can't DMA directly from a file cache page unless you have a
> > network card that does scatter/gather DMA and surprise surprise,
> > 80-90% of the cards on the market don't support this.
On Sat, 2 Sep 2000, Jeff V. Merkey wrote:
> **ALL** Netware network drivers support a scatter/gather proramming
> interface, whether the hardware does or not. In NetWare, the drivers
> get passed a fragment list in what's called an ECB (Event Control
> Block). It's the drivers responsiblity to a
On Sat, 2 Sep 2000, Jeff V. Merkey wrote:
> Alan, Please. I'm in your code and there are copies all over the
> place. I agree you have a "fast path" for most stuff, but there's
> all kinds of handles lookups, linear list searching like
have you ever bothered actually measuring the impact? I hav
On Sat, 2 Sep 2000, Jeff V. Merkey wrote:
> while (x)
> {
> x = x->next
> }
>
> all over the place that increases latency. [...]
i challenge you to show one such place in the 2.4.0-test8-pre2 kernel. If
it's all over the place and if it increases latency, you certainly can
show at least one
On 2 Sep 2000, Jes Sorensen wrote:
> You can't DMA directly from a file cache page unless you have a
> network card that does scatter/gather DMA and surprise surprise,
> 80-90% of the cards on the market don't support this. [...]
exactly. The TUX patch solves this by copying 'multi-fragment skb
In article <[EMAIL PROTECTED]>,
Jamie Lokier <[EMAIL PROTECTED]> wrote:
>
>I just thought I'd mention that you can do zero copy TCP in and out
>*without* any page marking schemes. All you need is a network card with
>quite a lot of RAM and some intelligence. An Alteon could do it, with
>extra R
Petr,
I could give you a packet burst module to study. It's MANOS version and
not linux, so you will need to backport it, but it will let you fake out
a NetWare server without needing all this memory.
Jeff
Petr Vandrovec wrote:
>
> On Sun, Sep 03, 2000 at 12:00:13AM +0100, Alan Cox wrote:
>
Jes Sorensen wrote:
> You can't DMA directly from a file cache page unless you have a
> network card that does scatter/gather DMA and surprise surprise,
> 80-90% of the cards on the market don't support this. Besides that you
> need to do copy-on-write if you want to be able to do zero copy on
> w
On Sun, Sep 03, 2000 at 12:00:13AM +0100, Alan Cox wrote:
> > **NCP** is does not reside in IPX at all. That's why the implementation
> > in Linux is busted. The window size is variable and keys off of HOW
> > MANY FREE ECBS ARE IN THE SYSTEM. It doe not belong in the IPX/SPX
> > stack, but ins
Alan Cox wrote:
>
>
> > **NCP** is does not reside in IPX at all. That's why the implementation
> > in Linux is busted. The window size is variable and keys off of HOW
> > MANY FREE ECBS ARE IN THE SYSTEM. It doe not belong in the IPX/SPX
> > stack, but inside of MARS-NWE proper.
>
> Packet
There's been a few cards around since about 1995, but I don't remember
all of them. I do remember having to debug SMP code on them though --
yec
Jeff
Jes Sorensen wrote:
>
> > "Jeff" == Jeff V Merkey <[EMAIL PROTECTED]> writes:
>
> Jeff> Jes Sorensen wrote:
> >> You just told us
> "Jeff" == Jeff V Merkey <[EMAIL PROTECTED]> writes:
Jeff> Jes Sorensen wrote:
>> You just told us earlier in the thread that NetWare does direct
>> zero copy DMA but thats only half the story obviously. Up until the
>> era of Gigabit Ethernet cards there were almost no PCI cards
>> availab
> There is a checksum field in IPX, but it always contains x. Drew
> always assumed upper layer programs, like NDS, would do heir own
> checksumming for integrity, and in fact, this is how it's instrumented
> in NetWare.
Which is actually a design flaw on a modern architecture since it may c
Andi Kleen wrote:
>
> On Sat, Sep 02, 2000 at 04:28:18PM -0600, Jeff V. Merkey wrote:
> >
> >
> > Alan Cox wrote:
> > >
> > > We dont copy for checksumming. We fold the single user space copy and the
> > > checksum operation into one path, because on any modern CPU it costs precisely
> > > the
Alan,
I'm impressed!!! You do understand NetWare architecture very well.
Some corrections though.
Alan Cox wrote:
>
> > You just told us earlier in the thread that NetWare does direct zero
> > copy DMA but thats only half the story obviously. Up until the era of
> > Gigabit Ethernet cards th
On Sat, Sep 02, 2000 at 04:28:18PM -0600, Jeff V. Merkey wrote:
>
>
> Alan Cox wrote:
> >
> > We dont copy for checksumming. We fold the single user space copy and the
> > checksum operation into one path, because on any modern CPU it costs precisely
> > the same to copy as to copy/checksum.
>
Jes Sorensen wrote:
>
> > "Jeff" == Jeff V Merkey <[EMAIL PROTECTED]> writes:
>
> Jeff> **ALL** Netware network drivers support a scatter/gather
> Jeff> proramming interface, whether the hardware does or not. In
> Jeff> NetWare, the drivers get passed a fragment list in what's called
> Je
1 - 100 of 116 matches
Mail list logo
