[dpdk-dev] [PATCH v3 2/2] virtio/vdev: add a new vdev named eth_cvio
Hi, On 4/22/2016 3:36 PM, David Marchand wrote: > Hello, > > On Fri, Apr 22, 2016 at 7:15 AM, Tan, Jianfeng > wrote: >> On 4/21/2016 4:51 PM, David Marchand wrote: >>> virtio code relies on drv_flags (even updating it while this should be >>> per-device). >>> So first, virtio should rely on dev_flags. >> >> Mainly drv_flags's RTE_PCI_DRV_INTR_LSC, and RTE_PCI_DRV_DETACHABLE bit is >> used. I understand the issue, pointed out by you here, that if two virtio >> devices are used in a VM, one with feature VIRTIO_NET_F_STATUS, and the >> other without feature VIRTIO_NET_F_STATUS (under the case that two vhost >> backends are used). Then it leads to uncertainty of the behavior. >> >> Since the flags has been copied into dev_flags after features negotiated, I >> believe we should use dev_flags instead of drv_flags. A patch to fix this >> will be sent. > Ok. > >>> The rest needs to be astracted in some virtio ops ? >> So with that fix goes, we may make it more clear now. Do you mean this? > Well, here, we have what looks like to be two drivers (one pci and one vdev). > You tried to keep all this code together, to avoid duplicating it, > which sounds sane. > But in the end, you are trying to make this work by adding checks > where this can't. > I am not saying we should duplicate the code, but maybe having some > internal virtio ops / abstraction would do the trick and avoid those > checks. > > > The reason of those comments is that dev_type in ethdev is going to > disappear, see [1] and [2]. > Drivers are called through their own specific ethdev/crypto ops and > so, those drivers know implicitely that their are either pci or vdev > (or whatever in the future) drivers. > > > [1]: http://dpdk.org/ml/archives/dev/2016-April/037686.html > [2]: http://dpdk.org/ml/archives/dev/2016-January/031390.html Thank you for this import information. A quick check, we can remove those checks, as you said, to virtio ops. Great! Thanks, Jianfeng
[dpdk-dev] [PATCH v3 2/2] virtio/vdev: add a new vdev named eth_cvio
Hi Yuanhan,
On 4/22/2016 6:14 AM, Yuanhan Liu wrote:
> On Thu, Apr 21, 2016 at 02:56:36AM +, Jianfeng Tan wrote:
>> Add a new virtual device named eth_cvio, it can be used just like
>> eth_ring, eth_null, etc.
>>
>> Configured parameters include:
>>- rx (optional, 1 by default), number of rx, not used for now.
>>- tx (optional, 1 by default), number of tx, not used for now.
>>- cq (optional, 0 by default), not supported for now.
>>- mac (optional), random value will be given if not specified.
>>- queue_size (optional, 256 by default), size of virtqueue.
>>- path (madatory), path of vhost, depends on the file type, vhost
>> user if the given path points to a unix socket; vhost-net if the
>> given path points to a char device.
>>- ifname (optional), specify the name of backend tap device; only
>> valid when backend is vhost-net.
>>
>> The major difference with original virtio for vm is that, here we use
>> virtual addr instead of physical addr for vhost to calculate relative
>> address.
>>
>> When enable CONFIG_RTE_VIRTIO_VDEV (enabled by default), the compiled
>> library can be used in both VM and container environment.
>>
>> Examples:
>> path_vhost=/dev/vhost-net # use vhost-net as a backend
>> path_vhost= # use vhost-user as a backend
>>
>> sudo ./examples/l2fwd/build/l2fwd -c 0x10 -n 4 \
>> --socket-mem 0,1024 --no-pci --file-prefix=l2fwd \
>> --vdev=eth_cvio0,mac=00:01:02:03:04:05,path=$path_vhost -- -p 0x1
>>
>> Known issues:
>> - Control queue and multi-queue are not supported yet.
>> - Cannot work with --huge-unlink.
>> - Cannot work with no-huge.
>> - Cannot work when there are more than VHOST_MEMORY_MAX_NREGIONS(8)
>> hugepages.
>> - Root privilege is a must (mainly becase of sorting hugepages according
>> to physical address).
>> - Applications should not use file name like HUGEFILE_FMT ("%smap_%d").
>>
>> Signed-off-by: Huawei Xie
>> Signed-off-by: Jianfeng Tan
>> Acked-By: Neil Horman
>> ---
>> doc/guides/nics/overview.rst | 58 +-
>> doc/guides/rel_notes/release_16_07.rst | 4 +
>> drivers/net/virtio/rte_eth_virtio_vdev.c | 188
>> ++-
> Why prefixing it with "rte_eth_..."?
I was to make align with other virtual devices, like ring, null, etc.
But like suggested by Thomas and you, I'll rename it.
>
>> - = = = = = = = = = = = = = = = = = = = = = = = = = =
>> = = = = = = = = =
>> - Feature a b b b c e e e i i i i i i i i i i f f f f m m m n
>> n p r s v v v v x
>> -f n n o x 1 n n 4 4 4 4 g g x x x x m m m m l l p f
>> u c i z h i i m e
>> -p x x n g 0 a i 0 0 0 0 b b g g g g 1 1 1 1 x x i p
>> l a n e o r r x n
>> -a 2 2 d b 0 c e e e e v b b b b 0 0 0 0 4 5 p
>> l p g d s t t n v
>> -c x x i e 0 . v v f e e e e k k k k e
>> a t i i e i
>> -k v n . f f . v v . v v
>> t o o t r
>> -e f g . . . f f . f f
>> a . 3 t
>> + = = = = = = = = = = = = = = = = = = = = = = = = = =
>> = = = = = = = = = =
>> + Feature a b b b c e e e i i i i i i i i i i f f f f m m m n
>> n p r s v v v v x c
>> +f n n o x 1 n n 4 4 4 4 g g x x x x m m m m l l p f
>> u c i z h i i m e v
>> +p x x n g 0 a i 0 0 0 0 b b g g g g 1 1 1 1 x x i p
>> l a n e o r r x n i
>> +a 2 2 d b 0 c e e e e v b b b b 0 0 0 0 4 5 p
>> l p g d s t t n v r
>> +c x x i e 0 . v v f e e e e k k k k e
>> a t i i e i t
>> +k v n . f f . v v . v v
>> t o o t r i
>> +e f g . . . f f . f f
>> a . 3 t o
>> t v v v v v v
>>2 v
>
> I would wish we have a diff that could do compare by columns but not by
> rows :)
>
>
>> diff --git a/drivers/net/virtio/virtio_pci.h
>> b/drivers/net/virtio/virtio_pci.h
>> index 68097e6..3b47332 100644
>> --- a/drivers/net/virtio/virtio_pci.h
>> +++ b/drivers/net/virtio/virtio_pci.h
>> @@ -264,7 +264,7 @@ struct virtio_hw {
>> #define VHOST_KERNEL 0
>> #define VHOST_USER 1
>> int type; /* type of backend */
>> -uint32_tqueue_num;
>> +uint32_tqueue_size;
> Hmm, this kind of change should not be squeezed here, stealthily. I
> would agree that the rename in decreases the stealthily, which is a
> good thing. You should submit a standalone patch instead.
Nice catch. I should do it in the first commit when it's defined.
Thank,
Jianfeng
>
> --yliu
[dpdk-dev] [PATCH v3 2/2] virtio/vdev: add a new vdev named eth_cvio
Hi Thomas, On 4/21/2016 6:05 PM, Thomas Monjalon wrote: > 2016-04-21 02:56, Jianfeng Tan: >> Add a new virtual device named eth_cvio, it can be used just like >> eth_ring, eth_null, etc. > Why this name eth_cvio? > Why the prefix eth_? > The virtio-net driver uses a kernel device. Here it is a userland device. > Why not virtio-user? I was looking for an appropriate name for this device; have tried a lot, but none is good enough. Thank you for your advice virtio-user. The prefix eth_ is to keep the same style with eth_ring, eth_null. So how about eth_virtio_user? > >> .. table:: Features availability in networking drivers >> >> - = = = = = = = = = = = = = = = = = = = = = = = = = = >> = = = = = = = = = >> - Feature a b b b c e e e i i i i i i i i i i f f f f m m m n >> n p r s v v v v x >> -f n n o x 1 n n 4 4 4 4 g g x x x x m m m m l l p f >> u c i z h i i m e >> -p x x n g 0 a i 0 0 0 0 b b g g g g 1 1 1 1 x x i p >> l a n e o r r x n >> -a 2 2 d b 0 c e e e e v b b b b 0 0 0 0 4 5 p >> l p g d s t t n v >> -c x x i e 0 . v v f e e e e k k k k e >> a t i i e i >> -k v n . f f . v v . v v >> t o o t r >> -e f g . . . f f . f f >> a . 3 t >> + = = = = = = = = = = = = = = = = = = = = = = = = = = >> = = = = = = = = = = >> + Feature a b b b c e e e i i i i i i i i i i f f f f m m m n >> n p r s v v v v x c >> +f n n o x 1 n n 4 4 4 4 g g x x x x m m m m l l p f >> u c i z h i i m e v >> +p x x n g 0 a i 0 0 0 0 b b g g g g 1 1 1 1 x x i p >> l a n e o r r x n i >> +a 2 2 d b 0 c e e e e v b b b b 0 0 0 0 4 5 p >> l p g d s t t n v r >> +c x x i e 0 . v v f e e e e k k k k e >> a t i i e i t >> +k v n . f f . v v . v v >> t o o t r i >> +e f g . . . f f . f f >> a . 3 t o >> t v v v v v v >>2 v >> e e e e e e >> e >> c c c c c c >> c >> - = = = = = = = = = = = = = = = = = = = = = = = = = = >> = = = = = = = = = > Please keep the alphabetical order. OK, I'll do it in next version. Thanks, Jianfeng
[dpdk-dev] [PATCH v3 2/2] virtio/vdev: add a new vdev named eth_cvio
Hi, On 4/21/2016 4:51 PM, David Marchand wrote: > Hello, > > On Thu, Apr 21, 2016 at 4:56 AM, Jianfeng Tan > wrote: >> Add a new virtual device named eth_cvio, it can be used just like >> eth_ring, eth_null, etc. >> >> Configured parameters include: >>- rx (optional, 1 by default), number of rx, not used for now. >>- tx (optional, 1 by default), number of tx, not used for now. >>- cq (optional, 0 by default), not supported for now. >>- mac (optional), random value will be given if not specified. >>- queue_size (optional, 256 by default), size of virtqueue. >>- path (madatory), path of vhost, depends on the file type, vhost >> user if the given path points to a unix socket; vhost-net if the >> given path points to a char device. >>- ifname (optional), specify the name of backend tap device; only >> valid when backend is vhost-net. >> >> The major difference with original virtio for vm is that, here we use >> virtual addr instead of physical addr for vhost to calculate relative >> address. >> >> When enable CONFIG_RTE_VIRTIO_VDEV (enabled by default), the compiled >> library can be used in both VM and container environment. > This implementation heavily relies on dev_type to keep as much code > shared between pci / vdev path as possible. Yes, I still have no method to make it more clear. > > virtio code relies on drv_flags (even updating it while this should be > per-device). > So first, virtio should rely on dev_flags. Mainly drv_flags's RTE_PCI_DRV_INTR_LSC, and RTE_PCI_DRV_DETACHABLE bit is used. I understand the issue, pointed out by you here, that if two virtio devices are used in a VM, one with feature VIRTIO_NET_F_STATUS, and the other without feature VIRTIO_NET_F_STATUS (under the case that two vhost backends are used). Then it leads to uncertainty of the behavior. Since the flags has been copied into dev_flags after features negotiated, I believe we should use dev_flags instead of drv_flags. A patch to fix this will be sent. > > The rest needs to be astracted in some virtio ops ? So with that fix goes, we may make it more clear now. Do you mean this? Thanks, Jianfeng > > > Thanks. >
[dpdk-dev] [PATCH v3 2/2] virtio/vdev: add a new vdev named eth_cvio
2016-04-22 15:26, Tan, Jianfeng: > Hi Thomas, > > On 4/21/2016 6:05 PM, Thomas Monjalon wrote: > > 2016-04-21 02:56, Jianfeng Tan: > >> Add a new virtual device named eth_cvio, it can be used just like > >> eth_ring, eth_null, etc. > > Why this name eth_cvio? > > Why the prefix eth_? > > The virtio-net driver uses a kernel device. Here it is a userland device. > > Why not virtio-user? > > I was looking for an appropriate name for this device; have tried a lot, > but none is good enough. Thank you for your advice virtio-user. > The prefix eth_ is to keep the same style with eth_ring, eth_null. > So how about eth_virtio_user? I prefer not adding eth_. Just my opinion.
[dpdk-dev] [PATCH v3 2/2] virtio/vdev: add a new vdev named eth_cvio
Hello, On Fri, Apr 22, 2016 at 7:15 AM, Tan, Jianfeng wrote: > On 4/21/2016 4:51 PM, David Marchand wrote: >> virtio code relies on drv_flags (even updating it while this should be >> per-device). >> So first, virtio should rely on dev_flags. > > > Mainly drv_flags's RTE_PCI_DRV_INTR_LSC, and RTE_PCI_DRV_DETACHABLE bit is > used. I understand the issue, pointed out by you here, that if two virtio > devices are used in a VM, one with feature VIRTIO_NET_F_STATUS, and the > other without feature VIRTIO_NET_F_STATUS (under the case that two vhost > backends are used). Then it leads to uncertainty of the behavior. > > Since the flags has been copied into dev_flags after features negotiated, I > believe we should use dev_flags instead of drv_flags. A patch to fix this > will be sent. Ok. >> The rest needs to be astracted in some virtio ops ? > So with that fix goes, we may make it more clear now. Do you mean this? Well, here, we have what looks like to be two drivers (one pci and one vdev). You tried to keep all this code together, to avoid duplicating it, which sounds sane. But in the end, you are trying to make this work by adding checks where this can't. I am not saying we should duplicate the code, but maybe having some internal virtio ops / abstraction would do the trick and avoid those checks. The reason of those comments is that dev_type in ethdev is going to disappear, see [1] and [2]. Drivers are called through their own specific ethdev/crypto ops and so, those drivers know implicitely that their are either pci or vdev (or whatever in the future) drivers. [1]: http://dpdk.org/ml/archives/dev/2016-April/037686.html [2]: http://dpdk.org/ml/archives/dev/2016-January/031390.html -- David Marchand
[dpdk-dev] [PATCH v3 2/2] virtio/vdev: add a new vdev named eth_cvio
On Thu, Apr 21, 2016 at 02:56:36AM +, Jianfeng Tan wrote:
> Add a new virtual device named eth_cvio, it can be used just like
> eth_ring, eth_null, etc.
>
> Configured parameters include:
> - rx (optional, 1 by default), number of rx, not used for now.
> - tx (optional, 1 by default), number of tx, not used for now.
> - cq (optional, 0 by default), not supported for now.
> - mac (optional), random value will be given if not specified.
> - queue_size (optional, 256 by default), size of virtqueue.
> - path (madatory), path of vhost, depends on the file type, vhost
> user if the given path points to a unix socket; vhost-net if the
> given path points to a char device.
> - ifname (optional), specify the name of backend tap device; only
> valid when backend is vhost-net.
>
> The major difference with original virtio for vm is that, here we use
> virtual addr instead of physical addr for vhost to calculate relative
> address.
>
> When enable CONFIG_RTE_VIRTIO_VDEV (enabled by default), the compiled
> library can be used in both VM and container environment.
>
> Examples:
> path_vhost=/dev/vhost-net # use vhost-net as a backend
> path_vhost= # use vhost-user as a backend
>
> sudo ./examples/l2fwd/build/l2fwd -c 0x10 -n 4 \
> --socket-mem 0,1024 --no-pci --file-prefix=l2fwd \
> --vdev=eth_cvio0,mac=00:01:02:03:04:05,path=$path_vhost -- -p 0x1
>
> Known issues:
> - Control queue and multi-queue are not supported yet.
> - Cannot work with --huge-unlink.
> - Cannot work with no-huge.
> - Cannot work when there are more than VHOST_MEMORY_MAX_NREGIONS(8)
>hugepages.
> - Root privilege is a must (mainly becase of sorting hugepages according
>to physical address).
> - Applications should not use file name like HUGEFILE_FMT ("%smap_%d").
>
> Signed-off-by: Huawei Xie
> Signed-off-by: Jianfeng Tan
> Acked-By: Neil Horman
> ---
> doc/guides/nics/overview.rst | 58 +-
> doc/guides/rel_notes/release_16_07.rst | 4 +
> drivers/net/virtio/rte_eth_virtio_vdev.c | 188
> ++-
Why prefixing it with "rte_eth_..."?
> - = = = = = = = = = = = = = = = = = = = = = = = = = =
> = = = = = = = = =
> - Feature a b b b c e e e i i i i i i i i i i f f f f m m m n
> n p r s v v v v x
> -f n n o x 1 n n 4 4 4 4 g g x x x x m m m m l l p f
> u c i z h i i m e
> -p x x n g 0 a i 0 0 0 0 b b g g g g 1 1 1 1 x x i p
> l a n e o r r x n
> -a 2 2 d b 0 c e e e e v b b b b 0 0 0 0 4 5 p
> l p g d s t t n v
> -c x x i e 0 . v v f e e e e k k k k e
> a t i i e i
> -k v n . f f . v v . v v
> t o o t r
> -e f g . . . f f . f f
> a . 3 t
> + = = = = = = = = = = = = = = = = = = = = = = = = = =
> = = = = = = = = = =
> + Feature a b b b c e e e i i i i i i i i i i f f f f m m m n
> n p r s v v v v x c
> +f n n o x 1 n n 4 4 4 4 g g x x x x m m m m l l p f
> u c i z h i i m e v
> +p x x n g 0 a i 0 0 0 0 b b g g g g 1 1 1 1 x x i p
> l a n e o r r x n i
> +a 2 2 d b 0 c e e e e v b b b b 0 0 0 0 4 5 p
> l p g d s t t n v r
> +c x x i e 0 . v v f e e e e k k k k e
> a t i i e i t
> +k v n . f f . v v . v v
> t o o t r i
> +e f g . . . f f . f f
> a . 3 t o
> t v v v v v v
> 2 v
I would wish we have a diff that could do compare by columns but not by
rows :)
> diff --git a/drivers/net/virtio/virtio_pci.h b/drivers/net/virtio/virtio_pci.h
> index 68097e6..3b47332 100644
> --- a/drivers/net/virtio/virtio_pci.h
> +++ b/drivers/net/virtio/virtio_pci.h
> @@ -264,7 +264,7 @@ struct virtio_hw {
> #define VHOST_KERNEL 0
> #define VHOST_USER 1
> int type; /* type of backend */
> - uint32_tqueue_num;
> + uint32_tqueue_size;
Hmm, this kind of change should not be squeezed here, stealthily. I
would agree that the rename in decreases the stealthily, which is a
good thing. You should submit a standalone patch instead.
--yliu
[dpdk-dev] [PATCH v3 2/2] virtio/vdev: add a new vdev named eth_cvio
2016-04-21 02:56, Jianfeng Tan: > Add a new virtual device named eth_cvio, it can be used just like > eth_ring, eth_null, etc. Why this name eth_cvio? Why the prefix eth_? The virtio-net driver uses a kernel device. Here it is a userland device. Why not virtio-user? > .. table:: Features availability in networking drivers > > - = = = = = = = = = = = = = = = = = = = = = = = = = = > = = = = = = = = = > - Feature a b b b c e e e i i i i i i i i i i f f f f m m m n > n p r s v v v v x > -f n n o x 1 n n 4 4 4 4 g g x x x x m m m m l l p f > u c i z h i i m e > -p x x n g 0 a i 0 0 0 0 b b g g g g 1 1 1 1 x x i p > l a n e o r r x n > -a 2 2 d b 0 c e e e e v b b b b 0 0 0 0 4 5 p > l p g d s t t n v > -c x x i e 0 . v v f e e e e k k k k e > a t i i e i > -k v n . f f . v v . v v > t o o t r > -e f g . . . f f . f f > a . 3 t > + = = = = = = = = = = = = = = = = = = = = = = = = = = > = = = = = = = = = = > + Feature a b b b c e e e i i i i i i i i i i f f f f m m m n > n p r s v v v v x c > +f n n o x 1 n n 4 4 4 4 g g x x x x m m m m l l p f > u c i z h i i m e v > +p x x n g 0 a i 0 0 0 0 b b g g g g 1 1 1 1 x x i p > l a n e o r r x n i > +a 2 2 d b 0 c e e e e v b b b b 0 0 0 0 4 5 p > l p g d s t t n v r > +c x x i e 0 . v v f e e e e k k k k e > a t i i e i t > +k v n . f f . v v . v v > t o o t r i > +e f g . . . f f . f f > a . 3 t o > t v v v v v v > 2 v >e e e e e e >e >c c c c c c >c > - = = = = = = = = = = = = = = = = = = = = = = = = = = > = = = = = = = = = Please keep the alphabetical order.
[dpdk-dev] [PATCH v3 2/2] virtio/vdev: add a new vdev named eth_cvio
Hello, On Thu, Apr 21, 2016 at 4:56 AM, Jianfeng Tan wrote: > Add a new virtual device named eth_cvio, it can be used just like > eth_ring, eth_null, etc. > > Configured parameters include: > - rx (optional, 1 by default), number of rx, not used for now. > - tx (optional, 1 by default), number of tx, not used for now. > - cq (optional, 0 by default), not supported for now. > - mac (optional), random value will be given if not specified. > - queue_size (optional, 256 by default), size of virtqueue. > - path (madatory), path of vhost, depends on the file type, vhost > user if the given path points to a unix socket; vhost-net if the > given path points to a char device. > - ifname (optional), specify the name of backend tap device; only > valid when backend is vhost-net. > > The major difference with original virtio for vm is that, here we use > virtual addr instead of physical addr for vhost to calculate relative > address. > > When enable CONFIG_RTE_VIRTIO_VDEV (enabled by default), the compiled > library can be used in both VM and container environment. This implementation heavily relies on dev_type to keep as much code shared between pci / vdev path as possible. virtio code relies on drv_flags (even updating it while this should be per-device). So first, virtio should rely on dev_flags. The rest needs to be astracted in some virtio ops ? Thanks. -- David Marchand
[dpdk-dev] [PATCH v3 2/2] virtio/vdev: add a new vdev named eth_cvio
Add a new virtual device named eth_cvio, it can be used just like
eth_ring, eth_null, etc.
Configured parameters include:
- rx (optional, 1 by default), number of rx, not used for now.
- tx (optional, 1 by default), number of tx, not used for now.
- cq (optional, 0 by default), not supported for now.
- mac (optional), random value will be given if not specified.
- queue_size (optional, 256 by default), size of virtqueue.
- path (madatory), path of vhost, depends on the file type, vhost
user if the given path points to a unix socket; vhost-net if the
given path points to a char device.
- ifname (optional), specify the name of backend tap device; only
valid when backend is vhost-net.
The major difference with original virtio for vm is that, here we use
virtual addr instead of physical addr for vhost to calculate relative
address.
When enable CONFIG_RTE_VIRTIO_VDEV (enabled by default), the compiled
library can be used in both VM and container environment.
Examples:
path_vhost=/dev/vhost-net # use vhost-net as a backend
path_vhost= # use vhost-user as a backend
sudo ./examples/l2fwd/build/l2fwd -c 0x10 -n 4 \
--socket-mem 0,1024 --no-pci --file-prefix=l2fwd \
--vdev=eth_cvio0,mac=00:01:02:03:04:05,path=$path_vhost -- -p 0x1
Known issues:
- Control queue and multi-queue are not supported yet.
- Cannot work with --huge-unlink.
- Cannot work with no-huge.
- Cannot work when there are more than VHOST_MEMORY_MAX_NREGIONS(8)
hugepages.
- Root privilege is a must (mainly becase of sorting hugepages according
to physical address).
- Applications should not use file name like HUGEFILE_FMT ("%smap_%d").
Signed-off-by: Huawei Xie
Signed-off-by: Jianfeng Tan
Acked-By: Neil Horman
---
doc/guides/nics/overview.rst | 58 +-
doc/guides/rel_notes/release_16_07.rst | 4 +
drivers/net/virtio/rte_eth_virtio_vdev.c | 188 ++-
drivers/net/virtio/virtio_ethdev.c | 134 ++
drivers/net/virtio/virtio_ethdev.h | 3 +
drivers/net/virtio/virtio_pci.h | 2 +-
drivers/net/virtio/virtio_rxtx.c | 5 +-
drivers/net/virtio/virtio_rxtx_simple.c | 13 ++-
drivers/net/virtio/virtqueue.h | 10 ++
9 files changed, 326 insertions(+), 91 deletions(-)
diff --git a/doc/guides/nics/overview.rst b/doc/guides/nics/overview.rst
index ed116e3..1ff72fb 100644
--- a/doc/guides/nics/overview.rst
+++ b/doc/guides/nics/overview.rst
@@ -74,40 +74,40 @@ Most of these differences are summarized below.
.. table:: Features availability in networking drivers
- = = = = = = = = = = = = = = = = = = = = = = = = = = =
= = = = = = = =
- Feature a b b b c e e e i i i i i i i i i i f f f f m m m n n
p r s v v v v x
-f n n o x 1 n n 4 4 4 4 g g x x x x m m m m l l p f u
c i z h i i m e
-p x x n g 0 a i 0 0 0 0 b b g g g g 1 1 1 1 x x i p l
a n e o r r x n
-a 2 2 d b 0 c e e e e v b b b b 0 0 0 0 4 5 p l
p g d s t t n v
-c x x i e 0 . v v f e e e e k k k k e
a t i i e i
-k v n . f f . v v . v v
t o o t r
-e f g . . . f f . f f
a . 3 t
+ = = = = = = = = = = = = = = = = = = = = = = = = = = =
= = = = = = = = =
+ Feature a b b b c e e e i i i i i i i i i i f f f f m m m n n
p r s v v v v x c
+f n n o x 1 n n 4 4 4 4 g g x x x x m m m m l l p f u
c i z h i i m e v
+p x x n g 0 a i 0 0 0 0 b b g g g g 1 1 1 1 x x i p l
a n e o r r x n i
+a 2 2 d b 0 c e e e e v b b b b 0 0 0 0 4 5 p l
p g d s t t n v r
+c x x i e 0 . v v f e e e e k k k k e
a t i i e i t
+k v n . f f . v v . v v
t o o t r i
+e f g . . . f f . f f
a . 3 t o
t v v v v v v
2 v
e e e e e e
e
c c c c c c
c
- = = = = = = = = = = = = = = = = = = = = = = = = = = =
= = = = = = = =
+ = = = = = = = = = = = = = = = = = = = = = = = = = = =
= = = = = = = = =
speed capabilities
- link statusX X X X X X X X X X X X X X
X X X X
+ link statusX X X X X X X X X X X X X X
X X X X X
link status event X X X X X X X X X X
X
queue status event
