> >> Yes, you are correct that getting Xen dom0 out of the picture for > >> domU (guest) to outside communication is good. Crossbow is > providing > >> the framework to do just that. Their are various terms used like > >> Hybrid I/O (for SPARC implementation) and it can be done with > >> existing NICs like Sun's Neptune and Neterion's 10Gb NICs but > >> primarily on SPARC. With IOV, we will get the needed IOMMU > protection > >> to achieve this with any IOV capable NIC. And yes, if you directly > >> map the DMA channel and associated Rx ring into a domU, > the bandwidth > >> limiting/guarantees, priority and CPU association becomes moot > >> because you are dependent on "dynamic polling" from MAC layer for > >> some of these features. The moment the MAC layer is part > of domU (or > >> guest OS) and controlled by a hostile entity, > theoretically they can > >> circumvent the MAC layer running in domU (which they control). > > > > So with IOV and direct I/O access from within a > > DomU rate controlling can only be done in the actual > > H/W NIC. This means that you might loose a richer > set of > classification features, but you could gain > in network > performance. Do you collaborate with H/W > NIC developers in > this space, or provide some input > in what way NICs can be > improved to better support > rate controlling for > virtualized systems? > > > > Its more complicated than that. You really don't want the H/W > to start queuing on Rx and Tx and dropping packets is not > such a great idea (TCP really hurts on dropped packet). > So for instance on Tx, when you start exceeding the allowed > rate, the Crossbow MAC layer propogates the flow control all > the way upto the higher level queues (like TCP and UDP > Squeues) which can block the application generating the > traffic by putting it to sleep or failing the write. > Similarly on the Rx side, you drop packets only as a last > resort and you want to keep some elasticity. On 10Gig NIC, > this elasticity or ability to queue some before you drop can > start becoming expensive. The key thing is that H/W should > not be keeping any state. Its very slippery slope.
So that means you are doing L3/L4 classification even when you run on virtualized systems? When running VMs, how do you know L3 information for VMs as this is not in your control, but only in the hands of the VM user. It can change at any time. Is L3/L4 classification for virtualized systems efficient, as you would normally not inspect L3/L4 information within Dom0? > BTW, would you mind telling us what you are trying to do and > what is your interest? Thanks very much for giving great feedback on all my points. I work in the area of network virtualization, and I'm investigating how to do virtual network resource control in a very efficient and flexible manner. Cheers, Anna
