On Jan 24 2001, Mathieu Chouquet-Stringer wrote:
> Moreover, few ethernet cards are able to compute the ip checksum so
> linux doesn't need anymore to do that.
I'm very ignorant when it comes to Ethernet, but I'd like to
know which cards have this feature, as I'm planning on
> Do you mean that devices will not be able to indicate support of SG seperately
> from hw checksum or that the IP zerocopy will simply ignore devices which
> do not have both ?
>
> DECnet assumes that the mac level checksum will detect all errors and does
> not have a checksum of its own on
Do you mean that devices will not be able to indicate support of SG seperately
from hw checksum or that the IP zerocopy will simply ignore devices which
do not have both ?
DECnet assumes that the mac level checksum will detect all errors and does
not have a checksum of its own on data, so
On Jan 24 2001, Mathieu Chouquet-Stringer wrote:
Moreover, few ethernet cards are able to compute the ip checksum so
linux doesn't need anymore to do that.
I'm very ignorant when it comes to Ethernet, but I'd like to
know which cards have this feature, as I'm planning on buying
Ion Badulescu writes:
> I've attached a diff for the latest driver (and firmware) version, against
> 2.4.1pre10+zerocopy. Sorry about MIME, but my pine is currently broken
> (strips trailing spaces/tabs).
Ok.
Ion, I'll start to include your Starfire changes once the
firmware distribution
[EMAIL PROTECTED] writes:
> Dave, seems, it is better to repair this. Code really assumes
> that SG cannot be used without one of CSUM flags...
SG+CSUM requirement is enforced now in my tree, I will publish a newer
zerocopy patch later today.
Later,
David S. Miller
[EMAIL PROTECTED]
-
To
Ion Badulescu writes:
I've attached a diff for the latest driver (and firmware) version, against
2.4.1pre10+zerocopy. Sorry about MIME, but my pine is currently broken
(strips trailing spaces/tabs).
Ok.
Ion, I'll start to include your Starfire changes once the
firmware distribution issue
Hi Alexey,
On Sat, 27 Jan 2001 [EMAIL PROTECTED] wrote:
> > fits the new Linux model a bit better, as it has one descriptor per
> > packet, not one per fragment (like the current implementation).
>
> Yes. Absence of such mode with acenic is big pain in ass.
And, at least for the starfire,
Hello!
> verify this? The only way I can think of is to verify that the checksum
> field is zero initially, correct?
It is not zero. It contains checksum of pseudoheader.
> fits the new Linux model a bit better, as it has one descriptor per
> packet, not one per fragment (like the current
Hello!
verify this? The only way I can think of is to verify that the checksum
field is zero initially, correct?
It is not zero. It contains checksum of pseudoheader.
fits the new Linux model a bit better, as it has one descriptor per
packet, not one per fragment (like the current
Hi Alexey,
On Sat, 27 Jan 2001 [EMAIL PROTECTED] wrote:
fits the new Linux model a bit better, as it has one descriptor per
packet, not one per fragment (like the current implementation).
Yes. Absence of such mode with acenic is big pain in ass.
And, at least for the starfire, using
On Fri, 26 Jan 2001, Ion Badulescu wrote:
> Besides, I've done some more testing last night, and there are some
> problems. The FP doesn't seem to like tinygrams too much, every once in a
> while (but *not* always) it decides to send one with a bad checksum. I'm
> talking especially about telnet
On Fri, 26 Jan 2001, David S. Miller wrote:
> Firstly, I would not configure the card to drop packets with bad
> checksums. If you do this, the errors do not propagate into the
> correct ipv4 snmp tables, which is bad. Also consider the case where
> the card has some bug and it erroneously
Hello!
> drivers use it at this time, I see a grand total of 2 (hamachi and hme) in
Plus acenic in zerocopy.
Plus patch to do this is available for eepro100.
> I'm just wondering, if a card supports sg but *not* TX csum, is it worth
> it to make use of sg? eepro100 falls into this category..
Ion Badulescu writes:
> Well, in the meantime I've ported the starfire driver to the zerocopy
> framework, it now takes almost full advantage of the card sg+csum
> capabilities. The patch is attached; I'd appreciate it if you could
> include it into the main zerocopy patch.
Great, some
Ion Badulescu writes:
Well, in the meantime I've ported the starfire driver to the zerocopy
framework, it now takes almost full advantage of the card sg+csum
capabilities. The patch is attached; I'd appreciate it if you could
include it into the main zerocopy patch.
Great, some
On Fri, 26 Jan 2001, David S. Miller wrote:
Firstly, I would not configure the card to drop packets with bad
checksums. If you do this, the errors do not propagate into the
correct ipv4 snmp tables, which is bad. Also consider the case where
the card has some bug and it erroneously
Hello!
drivers use it at this time, I see a grand total of 2 (hamachi and hme) in
Plus acenic in zerocopy.
Plus patch to do this is available for eepro100.
I'm just wondering, if a card supports sg but *not* TX csum, is it worth
it to make use of sg? eepro100 falls into this category..
On Fri, 26 Jan 2001, Ion Badulescu wrote:
Besides, I've done some more testing last night, and there are some
problems. The FP doesn't seem to like tinygrams too much, every once in a
while (but *not* always) it decides to send one with a bad checksum. I'm
talking especially about telnet
On Thu, 25 Jan 2001, David S. Miller wrote:
> Ion Badulescu writes:
> > I'm just wondering, if a card supports sg but *not* TX csum, is it worth
> > it to make use of sg? eepro100 falls into this category..
>
> No, not worth it for now. In fact I'm going to mark that combination
> (sg without
[EMAIL PROTECTED] wrote:
>
> Hello!
>
> > no problems. I simply mounted an NFS server with rsize=wsize=8192
> > and read a few files - I assume this is sufficient?
>
> This is orthogonal.
>
> Only TCP uses this and you need not to do something special
> to test it. Any TCP connection going
Steve Whitehouse writes:
> Do you mean that devices will not be able to indicate support of SG seperately
> from hw checksum or that the IP zerocopy will simply ignore devices which
> do not have both ?
IP will ignore devices which do not have both.
> DECnet assumes that the mac level
Hi,
Do you mean that devices will not be able to indicate support of SG seperately
from hw checksum or that the IP zerocopy will simply ignore devices which
do not have both ?
DECnet assumes that the mac level checksum will detect all errors and does
not have a checksum of its own on data, so
Ion Badulescu writes:
> I'm just wondering, if a card supports sg but *not* TX csum, is it worth
> it to make use of sg? eepro100 falls into this category..
No, not worth it for now. In fact I'm going to mark that combination
(sg without csum) as illegal in the final zerocopy patch I end up
On Thu, 25 Jan 2001, David S. Miller wrote:
>
> Ion Badulescu writes:
> > Well, yes and no. It's not quite orthogonal, because normally TCP
> > will never transmit fragmented packets, and it's precisely fragmented
> > packets that make the interesting case with a card that supports
> >
Ion Badulescu writes:
> Well, yes and no. It's not quite orthogonal, because normally TCP
> will never transmit fragmented packets, and it's precisely fragmented
> packets that make the interesting case with a card that supports
> hardware TCP/UDP checksums.
No it is not the interesting
Hello!
> Starfire card does, maybe the 3com is different. :-)
3com _is_ different. 8)
I is not an issue, we do not make zerocopy on IP fragments.
> Are we even bothering with the partial checksums at this point, or
> are we falling back to CPU checksumming if the packet is fragmented?
Of
On Thu, 25 Jan 2001 22:29:14 +0300 (MSK), [EMAIL PROTECTED] wrote:
> Hello!
>
>> no problems. I simply mounted an NFS server with rsize=wsize=8192
>> and read a few files - I assume this is sufficient?
>
> This is orthogonal.
>
> Only TCP uses this and you need not to do something special
>
Hello!
> no problems. I simply mounted an NFS server with rsize=wsize=8192
> and read a few files - I assume this is sufficient?
This is orthogonal.
Only TCP uses this and you need not to do something special
to test it. Any TCP connection going through 3c tests it.
> rather than using the
Andrew Morton writes:
> What I suggest we do here is to add a new flag to the per-device
> table `HAS_HWCKSM' and use that to set the device capabilities,
> rather than using the IS_CYCLONE stuff. Then we can add cards
> individually as confirmation comes in.
This idea sounds just fine.
Andrew Morton writes:
What I suggest we do here is to add a new flag to the per-device
table `HAS_HWCKSM' and use that to set the device capabilities,
rather than using the IS_CYCLONE stuff. Then we can add cards
individually as confirmation comes in.
This idea sounds just fine.
I
Hello!
no problems. I simply mounted an NFS server with rsize=wsize=8192
and read a few files - I assume this is sufficient?
This is orthogonal.
Only TCP uses this and you need not to do something special
to test it. Any TCP connection going through 3c tests it.
rather than using the
On Thu, 25 Jan 2001 22:29:14 +0300 (MSK), [EMAIL PROTECTED] wrote:
Hello!
no problems. I simply mounted an NFS server with rsize=wsize=8192
and read a few files - I assume this is sufficient?
This is orthogonal.
Only TCP uses this and you need not to do something special
to test it.
Hello!
Starfire card does, maybe the 3com is different. :-)
3com _is_ different. 8)
I is not an issue, we do not make zerocopy on IP fragments.
Are we even bothering with the partial checksums at this point, or
are we falling back to CPU checksumming if the packet is fragmented?
Of
[EMAIL PROTECTED] wrote:
Hello!
no problems. I simply mounted an NFS server with rsize=wsize=8192
and read a few files - I assume this is sufficient?
This is orthogonal.
Only TCP uses this and you need not to do something special
to test it. Any TCP connection going through 3c
On Thu, 25 Jan 2001, David S. Miller wrote:
Ion Badulescu writes:
I'm just wondering, if a card supports sg but *not* TX csum, is it worth
it to make use of sg? eepro100 falls into this category..
No, not worth it for now. In fact I'm going to mark that combination
(sg without csum)
On Thu, 25 Jan 2001, David S. Miller wrote:
Ion Badulescu writes:
Well, yes and no. It's not quite orthogonal, because normally TCP
will never transmit fragmented packets, and it's precisely fragmented
packets that make the interesting case with a card that supports
hardware
Ion Badulescu writes:
I'm just wondering, if a card supports sg but *not* TX csum, is it worth
it to make use of sg? eepro100 falls into this category..
No, not worth it for now. In fact I'm going to mark that combination
(sg without csum) as illegal in the final zerocopy patch I end up
Hi,
Do you mean that devices will not be able to indicate support of SG seperately
from hw checksum or that the IP zerocopy will simply ignore devices which
do not have both ?
DECnet assumes that the mac level checksum will detect all errors and does
not have a checksum of its own on data, so
Ion Badulescu writes:
Well, yes and no. It's not quite orthogonal, because normally TCP
will never transmit fragmented packets, and it's precisely fragmented
packets that make the interesting case with a card that supports
hardware TCP/UDP checksums.
No it is not the interesting case
Steve Whitehouse writes:
Do you mean that devices will not be able to indicate support of SG seperately
from hw checksum or that the IP zerocopy will simply ignore devices which
do not have both ?
IP will ignore devices which do not have both.
DECnet assumes that the mac level checksum
"David S. Miller" wrote:
>
> I'm back from OZ, and to help deal with my sudden lack of Victoria
> Bitter,
aww.. Poor Dave. I'll have an extra one for you.
> ...
> There is one critical failure I saw reported with zerocopy, where all
> transmits basically failed using a 3c59x card. This
[Jonathan Earle]
> Hmm.. so things like routing should be faster then?
Other network traffic too. Say you have an FTP server running and it
wants to send a file out to a client. The old way was for it to read()
the file into memory and then write() it to the network socket. To
avoid having
> > What are "zerocopy patch set"s?
>
> Basically, if you want to send something to the network, the
> kernel has to
> copy your data to its memory space. It is an overhead and with these
> patches, the kernel doesn't has to do it. So it is faster.
> Moreover, few
> ethernet cards are able to
[EMAIL PROTECTED] ("Jonathan Earle") writes:
> > I'm back from OZ, and to help deal with my sudden lack of Victoria
> > Bitter, I've made a new zerocopy patch set.
>
> What are "zerocopy patch set"s?
Basically, if you want to send something to the network, the kernel has to
copy your data to
> I'm back from OZ, and to help deal with my sudden lack of Victoria
> Bitter, I've made a new zerocopy patch set.
What are "zerocopy patch set"s?
Cheers!
Jon
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the
I'm back from OZ, and to help deal with my sudden lack of Victoria
Bitter, I've made a new zerocopy patch set. You will notice that
it is now significantly smaller than previous versions. This is
because all of the straight bug fixes and cleanups in my tree made
it into 2.4.1-pre10. What
[EMAIL PROTECTED] ("Jonathan Earle") writes:
I'm back from OZ, and to help deal with my sudden lack of Victoria
Bitter, I've made a new zerocopy patch set.
What are "zerocopy patch set"s?
Basically, if you want to send something to the network, the kernel has to
copy your data to its
What are "zerocopy patch set"s?
Basically, if you want to send something to the network, the
kernel has to
copy your data to its memory space. It is an overhead and with these
patches, the kernel doesn't has to do it. So it is faster.
Moreover, few
ethernet cards are able to compute
[Jonathan Earle]
Hmm.. so things like routing should be faster then?
Other network traffic too. Say you have an FTP server running and it
wants to send a file out to a client. The old way was for it to read()
the file into memory and then write() it to the network socket. To
avoid having to
I'm back from OZ, and to help deal with my sudden lack of Victoria
Bitter, I've made a new zerocopy patch set. You will notice that
it is now significantly smaller than previous versions. This is
because all of the straight bug fixes and cleanups in my tree made
it into 2.4.1-pre10. What
I'm back from OZ, and to help deal with my sudden lack of Victoria
Bitter, I've made a new zerocopy patch set.
What are "zerocopy patch set"s?
Cheers!
Jon
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the
"David S. Miller" wrote:
I'm back from OZ, and to help deal with my sudden lack of Victoria
Bitter,
aww.. Poor Dave. I'll have an extra one for you.
...
There is one critical failure I saw reported with zerocopy, where all
transmits basically failed using a 3c59x card. This indicates
53 matches
Mail list logo
