Hi,
---------- Původní zpráva ---------- Od: Agnieszka Tabaka <[email protected]> Komu: HelenOS development mailing list <[email protected]> Datum: 17. 3. 2014 20:37:14 Předmět: Re: [HelenOS-devel] A few questions regarding Ethernet driver implementation " On Mon, Mar 17, 2014 at 4:19 PM, Martin Decky <[email protected] (mailto:[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." " Not only that, but the TCP/IP stack cannot make use of the functionality either, so all bets are off as to whether any offload-related stuff that is present in the code is of any use at all. Also note that even if you succeeded in implementing some offloading, you are not likely to gain any significant performace since there are some pretty bad bottlenecks elsewhere (namely due to some bugs in TCP). " " " 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. " " It could be done - you could extend the interfaces to allow for specifying some kind of priority. Although I am not quite sure whether there is any good reason to give ARP/ICMP priority (nor I don't have any other idea what should be given priority and why). " 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 :) "The *previous* network stack we had in HelenOS had something like this and the *current* one deliberately does not. I do believe some parts of this are useful in particular context. Namely, a generic structure that allows you composing a binary string (i.e. packet) from parts. This is useful in context where the packet is stored in a memory shared by all the layers. Otherwise, packets at different layers are different beasts and need to be treated as such. Note however, that currently data is (deliberately) *copied* from process to process between the different network stack layers so there would be no use for such functionality. Best regards, Jiri
_______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
