Re: [Xen-devel][Pv-ops][PATCH 0/3] Resend: Netback multiple thread support

[Steven Smith <steven.smith@xxxxxxxxxx>]

> >> 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.

Attachment: signature.asc
Description: Digital signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel