Cleanup 'direct' VNIC semantics, preparing for offloads

[Jan Gutter]

The 'direct' VNIC type was closely associated with the hw_veb VIF type. Upstream OpenStack moved towards using the VNIC type to indicate offloading for the 'ovs' VIF type. It's therefore possible to specify that the combination of 'vrouter' VIF type, 'direct' VNIC type and no specified provider network should indicate that an offloaded VM port is requested.

[OpenContrail Admin (ci-admin-f)]

Review in progress for https://review.opencontrail.org/42478
Submitter: Jan Gutter (<email address hidden>)

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/42478
Committed: http://github.com/Juniper/contrail-controller/commit/60dca638de96a5224bb40e85e36228af3b6a60e1
Submitter: Zuul (<email address hidden>)
Branch: R4.1

commit 60dca638de96a5224bb40e85e36228af3b6a60e1
Author: Jan Gutter <email address hidden>
Date: Mon Apr 23 10:32:42 2018 +0200

[controller] Cleanup 'direct' VNIC semantics, preparing for offloads

Before this patch, the 'direct' VNIC type was closely associated with the
hw_veb VIF type. Upstream OpenStack moved towards using the VNIC type to
indicate offloading for the 'ovs' VIF type. It's therefore possible to
specify that the combination of 'vrouter' VIF type, 'direct' VNIC type and
no specified provider network would indicate that an offloaded VM port
is requested.

This patch removes the check for the hard association and allows the
cloud to create ports with that specific combination. Note that Nova
and vrouter-port-control still require updates in order to hook in the
accelerated ports. A future patch is intended to address that.

* src/config/api-server/vnc_cfg_types.py:
If a provider network is supplied and 'direct' VNIC type is requested,
the unmodified code path is used. Otherwise, a 'vrouter' VIF type is
requested with the offloaded VNIC type.

* src/vnsw/agent/oper/vm_interface_config.cc:
Only use the VM_SRIOV interface if the VIF type is 'hw_veb' and the
VNIC type is 'direct'. Otherwise, a standard vrouter interface is
used.

* src/vnsw/agent/test/test_util.cc:
Unit test has been updated.

Change-Id: Idee90abad334a00f2284ba5494f16beac2b0424e
Closes-Bug: #1766925
Signed-off-by: Jan Gutter <email address hidden>

[OpenContrail Admin (ci-admin-f)]

Review in progress for https://review.opencontrail.org/42850
Submitter: Jan Gutter (<email address hidden>)

[OpenContrail Admin (ci-admin-f)]

Review in progress for https://review.opencontrail.org/47586
Submitter: Jan Gutter (<email address hidden>)

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/42850
Committed: http://github.com/Juniper/contrail-controller/commit/0dfdc4bbd9057fc43868672a6111fb1dff6195ac
Submitter: Zuul v3 CI (<email address hidden>)
Branch: master

commit 0dfdc4bbd9057fc43868672a6111fb1dff6195ac
Author: Jan Gutter <email address hidden>
Date: Mon Apr 23 10:32:42 2018 +0200

[controller] Cleanup 'direct' VNIC semantics, preparing for offloads

Before this patch, the 'direct' VNIC type was closely associated with the
hw_veb VIF type. Upstream OpenStack moved towards using the VNIC type to
indicate offloading for the 'ovs' VIF type. It's therefore possible to
specify that the combination of 'vrouter' VIF type, 'direct' VNIC type and
no specified provider network would indicate that an offloaded VM port
is requested.

This patch removes the check for the hard association and allows the
cloud to create ports with that specific combination. Note that Nova
and vrouter-port-control still require updates in order to hook in the
accelerated ports. A future patch is intended to address that.

* src/config/api-server/vnc_cfg_types.py:
If a provider network is supplied and 'direct' VNIC type is requested,
the unmodified code path is used. Otherwise, a 'vrouter' VIF type is
requested with the offloaded VNIC type.

* src/vnsw/agent/oper/vm_interface_config.cc:
Only use the VM_SRIOV interface if the VIF type is 'hw_veb' and the
VNIC type is 'direct'. Otherwise, a standard vrouter interface is
used.

* src/vnsw/agent/test/test_util.cc:
Unit test has been updated.

Change-Id: I164f29371fbe8f816e4e7f797364a929b7ac74ff
Closes-Bug: #1766925
Signed-off-by: Jan Gutter <email address hidden>

[OpenContrail Admin (ci-admin-f)]

Reviewed: https://review.opencontrail.org/47586
Committed: http://github.com/Juniper/contrail-controller/commit/69b7cfe2721ea6093d9c354094c1dcff7cd9c3bf
Submitter: Zuul v3 CI (<email address hidden>)
Branch: R5.0

commit 69b7cfe2721ea6093d9c354094c1dcff7cd9c3bf
Author: Jan Gutter <email address hidden>
Date: Mon Apr 23 10:32:42 2018 +0200

[controller] Cleanup 'direct' VNIC semantics, preparing for offloads

Before this patch, the 'direct' VNIC type was closely associated with the
hw_veb VIF type. Upstream OpenStack moved towards using the VNIC type to
indicate offloading for the 'ovs' VIF type. It's therefore possible to
specify that the combination of 'vrouter' VIF type, 'direct' VNIC type and
no specified provider network would indicate that an offloaded VM port
is requested.

This patch removes the check for the hard association and allows the
cloud to create ports with that specific combination. Note that Nova
and vrouter-port-control still require updates in order to hook in the
accelerated ports. A future patch is intended to address that.

* src/config/api-server/vnc_cfg_types.py:
If a provider network is supplied and 'direct' VNIC type is requested,
the unmodified code path is used. Otherwise, a 'vrouter' VIF type is
requested with the offloaded VNIC type.

* src/vnsw/agent/oper/vm_interface_config.cc:
Only use the VM_SRIOV interface if the VIF type is 'hw_veb' and the
VNIC type is 'direct'. Otherwise, a standard vrouter interface is
used.

* src/vnsw/agent/test/test_util.cc:
Unit test has been updated.

Change-Id: I164f29371fbe8f816e4e7f797364a929b7ac74ff
Closes-Bug: #1766925
Signed-off-by: Jan Gutter <email address hidden>