On Tue, Nov 25, 2014 at 10:33:36PM -0500, Jamal Hadi Salim wrote:

On 11/25/14 16:54, Thomas Graf wrote:

quoted

On 11/25/14 at 12:08pm, Jamal Hadi Salim wrote:

quoted

It would definitely help if you could expose some more details on the
"some network processor" you have. We're all very eager ;-)

Well, this thing doesnt run ovs ;-> (/me runs). If you come
to netdev i may let you play with it ;-> Its a humongous device
(think multi 100G ports).

On a serious note: Even if you took what Simon/Netronome has
(yes, I know they use ovs;->)

FWIW, we are also interested in non-OVS use cases.

- there is really no need for a switch
abstraction *at all* if all you want to is hang a packet
processing graph that ingresses at a port and egress at another port.
As you know, Linux supports it just fine with tc.

I may be missing the point but I see two problems that are solved by
the switch abstraction.

- Cases where no ports are configured.

  Perhaps no such use cases exist for the API in question.
  But it does seem plausible to me that non-physical ports could
  be added at run-time and that thus a "switch" could initially
  exist with no configured port. Something like how bridges
  initially have no ports (IIRC).

- Discovering the association between ports and "switches".

My recollection from the double round table discussion on the last day of
the Düsseldorf sessions was that these were reasons that simply accessing
any port belonging to the "switch" were not entirely satisfactory.

quoted

I'm with Jiri but I agree it's not a perfect fit. I doubt there is but
if you can come up with something that fits better I'm open to it.

I considered "dataplane" or "dp" for a bit but it's quite generic as
well.

The purpose is to offload. I think any name would be better than
mapping it to a specific abstraction called "switch". Especially
if it is hanging off a port and there is no switch in the pipeline.

cheers,
jamal