> >> However if the NIC is multi-queued, which has only one interface but
> >> multiple interrupt queues. All netfronts are bounded with this
> >> interface via one bridge. We have no idea which interrupt queue is
> >> serving for
> >> a specified netfront. So the rebalance according to interrupt
> >> affinity is a challenge. Do you have idea on this point?
> > Sorry, I should have been clearer here. When I said ``interrupt'' I
> > meant the event channel interrupt which the netfront instance will use
> > to notify netback, not the physical hardware interrupt of whatever
> > physical NIC is ultimately associated with it. We should always know
> > which event channel a given netfront is using, and hence which
> > interrupt, and so we should be able to find out its affinity. In
> > effect, we'd rebalance in response to messages from the guest to
> > netback, which is at least vaguely reasonable as a proxy for actual
> > load.
>
> OK, I understand, what you were thinking about is on netfront TX,
> while I was talking about the netfront RX.
>
> In my solution, each tasklet PAIR will be assigned to a group. So I think
> the optimization should work for both directions.
Yep.
> As we have a common view that rebalance on RX rebalance is hard to
> implement, and the optimization point is on TX rebalance. Do you think
> if TX rebalance would have side effect on RX direction?
Most network traffic is at least a little bit symmetrical, so
rebalancing for TX should help at least a little bit for RX-heavy
workloads as well. There are some potential oddities if you have some
interfaces which are TX-heavy and some which are RX-heavy, though. I
think this needs more thought, and probably some experimentation,
before we can decide on the best approach.
Of course, there's no reason not to use a very simple balancer
initially (e.g. equal numbers of netifs in each group) and only do the
more complicated bits if it starts causing problems.
> However in my next version of patch, I would not include this logic
> since the change is not small and needs more effort.
Perfectly reasonable.
Steven.
signature.asc
Description: Digital signature
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home