yahoo-eng-team team mailing list archive

[Baptiste Jonglez <1976270@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

We have a bare-metal use-case where we plan to use Neutron and
networking-generic-switch (NGS) to reconfigure hardware switches, so
that bare-metal hosts can be configured in VLANs managed by Neutron.

However, we are facing a performance issue when creating or deleting
many ports at once, even when using Neutron's bulk API for creating
ports. The main issue is that Neutron binds ports sequentially, and
networking-generic-switch takes between 5s and 30s to bind a port
(depending on the hardware). Our use-case involves creating up to 10-100
ports at once, which means waiting several minutes for the API call to
complete: this is just too much.

We have ideas to improve NGS itself (SSH connection reuse, parallelism
across different switches), but the main blocker is the sequential
interface between Neutron and NGS. As a result, Neutron calls NGS with
only one port to bind at a time, and then waits for the bind to succeed
before calling again NGS with the next port to bind.

Here are some solutions we could think about, as a basis for discussion:

- add a new "bind_port_bulk()" interface between Neutron and mechanism
drivers, so that Neutron could pass all ports at once to NGS, and NGS
could then parallelize hardware reconfiguration. We started working on
this on the Neutron side, but it's quite invasive and difficult to do.
Pain points include error handling, atomicity, and interaction with
binding levels.

- add a way to bind ports asynchronously. Neutron could fire several
asynchronous bind calls to the mechanism driver, which would be handled
simultaneously by the driver (with appropriate asynchronous support).
Neutron would then "join" all the asynchronous threads before completing
the API call.

** Affects: neutron
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1976270

Title:
  [RFE] Improve performance of bulk port create/delete with networking-
  generic-switch

Status in neutron:
  New

Bug description:
  We have a bare-metal use-case where we plan to use Neutron and
  networking-generic-switch (NGS) to reconfigure hardware switches, so
  that bare-metal hosts can be configured in VLANs managed by Neutron.

  However, we are facing a performance issue when creating or deleting
  many ports at once, even when using Neutron's bulk API for creating
  ports. The main issue is that Neutron binds ports sequentially, and
  networking-generic-switch takes between 5s and 30s to bind a port
  (depending on the hardware). Our use-case involves creating up to
  10-100 ports at once, which means waiting several minutes for the API
  call to complete: this is just too much.

  We have ideas to improve NGS itself (SSH connection reuse, parallelism
  across different switches), but the main blocker is the sequential
  interface between Neutron and NGS. As a result, Neutron calls NGS with
  only one port to bind at a time, and then waits for the bind to
  succeed before calling again NGS with the next port to bind.

  Here are some solutions we could think about, as a basis for
  discussion:

  - add a new "bind_port_bulk()" interface between Neutron and mechanism
  drivers, so that Neutron could pass all ports at once to NGS, and NGS
  could then parallelize hardware reconfiguration. We started working on
  this on the Neutron side, but it's quite invasive and difficult to do.
  Pain points include error handling, atomicity, and interaction with
  binding levels.

  - add a way to bind ports asynchronously. Neutron could fire several
  asynchronous bind calls to the mechanism driver, which would be
  handled simultaneously by the driver (with appropriate asynchronous
  support). Neutron would then "join" all the asynchronous threads
  before completing the API call.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1976270/+subscriptions