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 buyin
> 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
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 iss
[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 unsu
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
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 impl
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 veri
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 comme
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 th
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 check
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 it
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
s
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
> > hardwa
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
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 cou
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
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 I
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.
>
"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 indica
[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
> > 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 c
[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 it
> 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 F
26 matches
Mail list logo
