On Mon, Mar 17, 2014 at 4:19 PM, Martin Decky <[email protected]> wrote:
> I'm planning to write RTL8169 driver as a GSoC project and have some >> questions regarding usage of some 'advanced' features of NICs in HelenOS. >> >> 1) What about checksum offloading? Can I make use of this feature in NIC >> driver to appropriately set offloading flags in TX descriptors? >> > > Theoretically speaking this should be possible and there should be even > some rudimentary support for that in our DDF NIC framework (see the IPC > methods NIC_OFFLOAD_PROBE and NIC_OFFLOAD_SET). > > Having said that, no existing NIC driver is using such capability (even on > devices that should support the feature), thus it is untested. > RTL8169 is a good example to test that feature... and it seems pretty straightforward to make use of it. > 2) RTL8169 have two separate TX queues (with separate descriptor rings). >> One is 'normal' queue and second is 'high priority' queue. Does it make >> sense for now to make use of both and prioritize the packets? Maybe some >> priority information may be guessed, i.e. putting ARP or ICMP packets in >> 'high priority' queue? >> > > Yes, this does make sense. But the network stack has currently no notion > of priorities or QoS, thus both the API and the implementation need to be > extended to support this, without hard-wiring it too much. > > Anyway, both ideas are definitively worth investigating, but for your GSoC > proposal I would keep them as optional items, if the time permits you to > engage them. > As I see, callback provided in nic_set_send_frame_handler() don't get any frame metadata such as frame priority, just plain buffer. So with existing DDF NIC framework the only option to get prioritization would be to decompose Ethernet frame and dig into IPv4 header looking for protocol type or TOS field, which is IMO a very bad idea - real-world prioritization will need deeper modifications in TCP/IP stack, so it will be probably out of scope of this project. However, I'll try to make TX path code reusable - adding support for second TX queue should be easy as possible. PS What about creating some system-wide linked-list-based structure to hold network frames? Something like sk_buff in linux, which: - will allow easy adding stacked headers (i.e TCP, IP and finally 802.3) by inserting buffers to head of the list - will hold packet metadata, such as priority or routing path - can be represented as contiguous structure in memory (defragmented) or converted to list of DMA descriptors That's just a some loose idea :) Agnieszka
_______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
