Nicolas Droux writes: > Project Nemo (http://opensolaris.org/os/community/networking/nemo- > design.pdf) aims at improving the performance, and accelerate the
May I ask questions about the document? I hope so, here I go.. BTW, I work for an IHV on a 10GbE nic driver. I have been encouraged to port to Nemo, so I'm reading this from the perspective of a driver developer. 3.7.2 mi_sdu_min "This should be set to the minimum payload size that can be conveyed by the media(5). 5: For DL_ETHER devices supporting jumbo frames this should still be set to ETHERMTU." I assume this is a typo, and this should be something like 60? Or (60 - 14) ? It looks like bge sets it to zero. Similarly: 3.7.3 mi_sdu_max "This should be set to the maximum payload size that can be conveyed by the media(6). 6 For DL_ETHER devices supporting jumbo frames this should still be set to ETHERMTU." How does a driver indicate he can handle jumbo frames? Bge, which I had been using for documentation, seems to set this to a jumbo value. 3.7.8 mi_stat: Will the stack maintain the statistics for things like MAC_STAT_IPACKETS if the driver fills in B_FALSE? 3.16 m_tx "Packets should beduled for transmission in the order in which they appear in the chain." "beduled?" I assume "scheduled" was intended? ;) 4.1.3 mac_resource_add Will anything go horribly wrong if my mrf_blank() does nothing with mrf_normal_pkt_cnt? We use only a timer. What is the unit for mrf_normal_blank_time? Microseconds? Our device will not notice a change to the interrupt interval until after the next interrupt happens and the state machine re-checks the interval. Is this OK? I could force the state machine to see this, but that could be very expensive.. 4.1.4 mac_resource_update "Invoked by the driver when the available resources have changed." What resources? What does this do? Is there a high level overview of this somewhere? I think I vaguely understand what is going on, but I need some help to see the full picture. It sounds like these resources can be used to hash TCP connections to different CPUs, ensuring each connection is always serialized. Is this correct? Does the hardware (or driver) need to do the hashing, or can the stack do it? In GLDv2, my driver hashes on the TCP header and separates packets into N taskqs (where N > 1 on CoolThreads systems). Then when the hardware interrupt handler returns, it schedules the taskq(s) that it fed packets to. Will this happen automatically for me in Nemo? 4.1.5 mac_rx "This function should be called to submit a chain of packets," A chain! Awesome! I like this. 4.1.6 mac_tx_update "This function is called by a driver to indicate that packet transmission resources are now available. The MAC module will send a notification" Can you explain how mac_tx_update() works in concert with m_tx() returning non-null? Please don't say it is like GLD_NORESOURCES, as I've never really understood that either ;) My fear is what happens in this scenario: - m_tx realizes he will return non-null - m_tx sets atomic "tx_update" driver flag - interrupt happens - interrupt handler notices that "tx_update" flag is set, and that he has cleaned sufficient ring entries such that he may clear "tx_update" and call mac_tx_update() - mac_tx_update() is called, does not find anything stopped - interrupt handler exits - m_tx returns non-NULL - nemo stops calling m_tx() At this point, it is possible that m_tx() may never be called again, if the interrupt cleaned all transmitted frames. Please tell me this is not possible. Probably enough ignorant questions for one day.. Thanks, Drew _______________________________________________ networking-discuss mailing list [email protected]
