Adam Greenhalgh wrote: > Hi, > > I've been playing with the ixgbe driver, I have reception for a single > queue working but am currently trying to get multiqueue support > working. > > Does any one have any thoughts on how click should handle NICs which > support multi queuing ? Our current thinking is that each queue needs > a separate click "poll" element to enable multithreading to work. > However this breaks the current poll element device ownership model.
I have not checked the manual extensively, but how does the card schedule which queue should be drained? Or do the queue owners cooperate in creating a schedule? My progress so far: I have managed to get the igb poll_on/off, tx_pqueue and tx_clean to work. I changed those functions to heavily rely on the already existing igb code. As a result, tx_eob and tx_start are just empty shells now. With the new code, I have managed to send 1.4 Mpps 64-byte frames. I still need to do the RX code before the driver becomes useful. Roman > > Adam > > 2008/8/18 Roman Chertov <[EMAIL PROTECTED]>: >> Hello, >> I am not sure how many people follow e1000, list but they have made >> a split between e1000 to e1000 and e1000e. There is also an igb driver >> which is pretty similar to e1000e code. We got 6 quad-port Intel which >> require the use of the igb driver. I am currently trying to port the >> igb driver to Click, and I am facing a few issues. The main issue is >> when the machine crashes, it has a tendency to damage the file system, >> so that even fsck cannot fix all the issues. I am curious if anybody >> had issues with crashes causing fs corruption and how the minimized the >> effects. >> >> Roman >> _______________________________________________ >> click mailing list >> [email protected] >> https://amsterdam.lcs.mit.edu/mailman/listinfo/click >> > _______________________________________________ click mailing list [email protected] https://amsterdam.lcs.mit.edu/mailman/listinfo/click
