Nicolas Droux writes:
> James Carlson wrote:
> > OK ... so I'll look into how to disable polling and force interrupt
> > mode for everything.  It looks like that should be possible to do, but
> > it's somewhat unclear in the code.
> 
> We can provide you the functions to enable/disable polling that you can 
> call from the bridging code. Someone on our team will look into the best 
> approach (either calling existing code or provide a new API) and 
> follow-up separately.

OK; thanks.  That'll help a good bit, as I'm likely to get hurt in
there.  If you want, you're welcome to look at and contribute directly
to the rbridges-on gate.  (That way, you can deliver the feature along
with an actual consumer, rather than trying to deliver to ON with no
consumer.)

My sense of it now is that it's important to get right, but likely not
a gating item in practice.  The reason is that:

  (a) The polling feature gets invoked in and is intended for
      situations where we're compute-bound due to network traffic on
      very high speed interfaces, and we need that incremental savings
      gained by avoiding interrupts.  Those are situations where the
      user is very performance sensitive and is trying to run right to
      the edge of what the hardware can do.  Those are exactly the
      users who will not want to use bridging, at least because of the
      cost of having all interfaces forced into promiscuous mode all
      of the time.  You do this on e1000g, but not nxge.

  (b) The failure mode that occurs effectively just results in packet
      loss when we're driven into polling mode.  Packet loss under
      very high utilization is unfortunate, but at some point, it's
      completely unavoidable.  This problem just makes it happen a
      little earlier in the performance curve.  (And it's unclear how
      much earlier, and whether with reasonable configurations it
      happens at all.)

It might not actually be a blocker.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

Reply via email to