Descriptor-Based NIC's

[01000101]

I just got through programming my newly purchased RTL8169s-32 based network cards. The biggest difference I noticed from the change from my RTL8139 based card was that both the recieve and transmission mechanisms relied upon descriptors. From what I understand, descriptors are just pockets of 16-byte wide memory locations in a chain-like formation that contain explanations of where the packet is located and such.

My question is: Are NICs more efficient (speed-wise) when using descriptors? I cant imaging that reading from a bunch of different memory locations could be faster than reading from one static location over and over again.

Also, programming for this particular card was 10x as difficult as I found out (the hard way) that sometimes the NIC completes a recieve/transmission operation but doesnt ACK during completion thus bringing the card to a standstill. This was very undocumented and I had to hack around for a while to figure it out. Just a side note.

[Candy]

The descriptor approach gives your OS the chance of setting up tens of transfers and then letting the card handle it. If you only have one location you can only set up 1 (or in the case of rtl8139 4) transactions. It reduces the interrupt overhead.

[jal]

II found out (the hard way) that sometimes the NIC completes a recieve/transmission operation but doesnt ACK during completion thus bringing the card to a standstill. This was very undocumented and I had to hack around for a while to figure it out. Just a side note.

This just seems like a bug in the card, not really an 'undocumented feature'. Or do you think there's a good reason for the card to act this way? Have you checked with the card's manufacturer's tech support?


JAL

[01000101]

Candy: What if I am running a complete polling-based setup? I would still have to do the same amount of work I suppose. Say I wanted to setup 4 transmission packets, I could parse and setup 4 seperate memory locations with one packet each, or I could setup 1 memory location 4 times, that seems pretty equal, or could memory caching help?

Jal: Well, the reason I believed it was an undocumented feature was because it would then act the same as the Recieve mechanism. In the recieve you actually have to set the ACK bit manually, so it would make sense that you would do it to the Transmission mech. as well, but not so says the datasheet, they said that it is self clearing upon successful transmission, even though the bit still does not clear after both the TxOK interrupt status bit is set and the Transmission POLL register says that the Tx buffer is empty. I have to do this for both of the cards in the system. Programming error? maybe, but I don't see how I could make the card not ACK, yet still transmit.

[Candy]

Candy: What if I am running a complete polling-based setup? I would still have to do the same amount of work I suppose. Say I wanted to setup 4 transmission packets, I could parse and setup 4 seperate memory locations with one packet each, or I could setup 1 memory location 4 times, that seems pretty equal, or could memory caching help?

You save cache line flushes, memory sharing, stuff like that.