-- 
Damjan

> On 7 Nov 2018, at 16:01, Coulson, Ken <kcoul...@ciena.com> wrote:
> 
> Our normal pattern for forwarding plane entities is create/modify/delete, the 
> TAP v1 API fit nicely with that.
> The desire is to support changing the interface after it's created without 
> deleting and re-creating to avoid as much potential traffic disruption as 
> possible.
> An example is MTU (which neither v1 or v2 support).  The desired maximum MTU 
> may not be known at creation time or may change depending on routing so a 
> modify capability seems appropriate.

VPP have universal API (hw_interface_set_mtu ) for setting MTU on all 
interfaces.

> So be specific on your questions, want to control MTU and admin/link 
> enable/disable, would like to know link status without polling.

VPP have universal API (sw_interface_set_flags ) for setting link and admin 
states.
You can subscribe to interface events with want_interface_events API to be 
notified on change.

>  
> DPDK TAP PMD (and vHost PMD) provide the same APIs as physical devices using 
> the rte_eth_dev_*() functions allowing the next layer of code to very similar 
> for physical and virtual devices.

In some cases we run vPP without DPDK, DPDK is just one device driver option 
for VPP.

> DPDK TAP PMD supports MTU,

see above

> jumbo frames

we support jumbo frames with tapv2.

> , extended statistics,

what exact extended statistic you are looking for?

> link status change notifications

see above

> plus likely other features.

like?

>   These seem to me to be an advantage and not a drawback. 
> I'm curious about the drawbacks mentioned and advantages of the VPP 
> implementation, could you provide a more detail?  More information will 
> certainly help!

main drawback  that it requires external dependency on DPDK which in some use 
cases we don't want.
Not sure if TAP PMD supports interrupt mode and dynamic interface 
creation/deletion but VPP native driver does.

Also all DPDK drivers have extra cost of converting metadata and dealing with 2 
more cachelines per packet in LLC (not big deal in case of tap)
so unless we really do bad job native driver will always be faster and simpler.

TAP interface is not rocket science, it may be that we are missing few features 
mainly due to my ignorance, but i don't expect anything what cannot be 
added/extended in few dozen lines of code.
I hope people will pick it up and contribute...

-- 
Damjan
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11146): https://lists.fd.io/g/vpp-dev/message/11146
Mute This Topic: https://lists.fd.io/mt/27873113/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to