OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Apr 18, 2024 8:59 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 5 posts ] 
Author Message
 Post subject: Descriptor-Based NIC's
PostPosted: Mon Jul 14, 2008 6:52 pm 
Offline
Member
Member
User avatar

Joined: Fri Jun 22, 2007 12:47 pm
Posts: 1598
Location: New Hampshire, USA
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.

_________________
Website: https://Joscor.com


Top
 Profile  
 
 Post subject: Re: Descriptor-Based NIC's
PostPosted: Tue Jul 15, 2008 3:32 am 
Offline
Member
Member
User avatar

Joined: Tue Oct 17, 2006 11:33 pm
Posts: 3882
Location: Eindhoven
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.


Top
 Profile  
 
 Post subject: Re: Descriptor-Based NIC's
PostPosted: Tue Jul 15, 2008 5:43 am 
Offline
Member
Member

Joined: Wed Oct 31, 2007 9:09 am
Posts: 1385
01000101 wrote:
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


Top
 Profile  
 
 Post subject: Re: Descriptor-Based NIC's
PostPosted: Tue Jul 15, 2008 6:38 am 
Offline
Member
Member
User avatar

Joined: Fri Jun 22, 2007 12:47 pm
Posts: 1598
Location: New Hampshire, USA
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.

_________________
Website: https://Joscor.com


Top
 Profile  
 
 Post subject: Re: Descriptor-Based NIC's
PostPosted: Tue Jul 15, 2008 10:04 am 
Offline
Member
Member
User avatar

Joined: Tue Oct 17, 2006 11:33 pm
Posts: 3882
Location: Eindhoven
01000101 wrote:
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: bookman, DotBot [Bot], SemrushBot [Bot] and 122 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group