[dpdk-dev] [RFC][PATCH V2 1/3] examples/vhost: Add vswitch (generic switch) framework
On 9/13/2016 12:21 PM, Tan, Jianfeng wrote:
Hi Jianfeng,
>>>
>>> On 9/5/2016 6:54 PM, Pankaj Chauhan wrote:
Introduce support for a generic framework for handling of switching
between
physical and vhost devices. The vswitch framework introduces the
following
concept:
1. vswitch_dev: Vswitch device is a logical switch which can have
physical and
virtio devices. The devices are operated/used using standard rte_eth
API for
physical devices and lib_vhost API for vhost devices, PMD API is not
used
for vhost devices.
2. vswitch_port: Any physical or virtio device that is added to
vswitch. The
port can have its own tx/rx functions for doing data transfer, which
are exposed
to the framework using generic function pointers
(vs_port->do_tx/do_rx). This way
the generic code can do tx/rx without understanding the type of device
(Physical or
virtio). Similarly each port has its own functions to select tx/rx
queues. The framework
provides default tx/rx queue selection functions to the port when port
is added
(for both physical and vhost devices). But the framework allows the
switch implementation
to override the queue selection functions (vs_port->get_txq/rxq) if
required.
3. vswitch_ops: The ops is set of function pointers which are used to
do operations
like learning, unlearning, add/delete port, lookup_and_forward. The
user of vswitch
framework (vhost/main.[c,h])uses these function pointers to perform
above mentioned
operations, thus it remains agnostic of the underlying implementation.
Different switching logics can implement their vswitch_device and
vswitch_ops, and
register with the framework. This framework makes vhost-switch
application scalable
in terms of:
1. Different switching logics (one of them is vmdq, vhost/vmdq.[c,h]
2. Number of ports.
3. Policies of selecting ports for rx and tx.
Signed-off-by: Pankaj Chauhan
>>>
>>> After this patch set, how's mapping relationship between cores and
>>> vswitch_dev? Old vhost example does not have the concept of switch, so
>>> each core is binded with some VDEVs. Now, we still keep original logic?
>>>
>>> (a) If yes, provided that phys device could has no direct relationship
>>> with vdevs in other switching logics, we may need to bind those physical
>>> devices to cores too? In that case, switch_worker() will receiving pkts
>>> from all devices (phys or virtual) and dispatch, which looks like:
>>>
>>> switch_worker() {
>>> FOR each port binding to this core {
>>> rx(port, pkts[], count);
>>> vs_lookup_n_fwd( information_needed );
>>> }
>>> }
>>
>> Since we support only one switch device running at one time. We bind
>> the ports of the switchdev to the core. But The switch might have it's
>> own logic to bind the port to the core. For example
>> VMDQ only supports one Physical port, other switch can support more
>> than one Physical port. In order to take care of that i have added two
>> ops in swithdev_ops:
>>
>> 1. vs_sched_rx_port:
>>
>> struct vswitch_port *vs_sched_rx_port(struct vswitch_dev *vs_dev, enum
>> vswitch_port_type ptype,
>> uint16_t core_id)
>>
>> 2. vs_sched_tx_port:
>>
>> struct vswitch_port *vs_sched_tx_port(struct vswitch_dev *vs_dev, enum
>> vswitch_port_type ptype, uint16_t
>> core_id)
>>
>> The idea of providing these functions is that vhost/main requests the
>> underlying switch implementation to schedule a port for rx or Tx, the
>> current running core_id is also passed as parameter. So the switch can
>> take a decision which port to do rx or tx based on core id, and may be
>> some other custom policy.
>>
>> For example VMDQ always returns the one single Physical port in
>> response to these functions called from any core. The other switch
>> can return the ports bound to the cores.
>>
>> Similarly there are two port operations (vs_port->get_rxq and
>> vs_port->get_txq), here also we pass core_id as parameter so that
>> the underlying switch implementation can schedule the rx or tx queue
>> based on the core_id.
>>
>> The above mentioned ops are used in drain_eth_rx() and
>> do_drain_mbuf_table() (main.c) currently, and they leave binding of
>> physical port and the queues to the underlying implementation. This
>> way we can accommodate VMDQ which uses only one physical port and
>> rxqueues based on VMDQ, OR any other switch which uses multiple
>> physical port and rx/tx queue scheduling based on some other logic.
>>
>> Please suggest if this way of scheduling ports and tx/rx queues is
>> fine or not?
>
> According to above explanation, in VMDQ switch, we cannot schedule two
> queues (belongs to the same port) on the same core, right?
>
Yes. This would be a limitation i believe which will not
[dpdk-dev] [RFC][PATCH V2 1/3] examples/vhost: Add vswitch (generic switch) framework
Hi Pankaj,
On 9/12/2016 6:55 PM, Pankaj Chauhan wrote:
> On 9/9/2016 2:26 PM, Tan, Jianfeng wrote:
>> Hi Pankaj,
>>
>> Thanks for the massive and great work.
>
> Hi Jianfeng,
>
> Thanks for the review.
>>
>> On 9/5/2016 6:54 PM, Pankaj Chauhan wrote:
>>> Introduce support for a generic framework for handling of switching
>>> between
>>> physical and vhost devices. The vswitch framework introduces the
>>> following
>>> concept:
>>>
>>> 1. vswitch_dev: Vswitch device is a logical switch which can have
>>> physical and
>>> virtio devices. The devices are operated/used using standard rte_eth
>>> API for
>>> physical devices and lib_vhost API for vhost devices, PMD API is not
>>> used
>>> for vhost devices.
>>>
>>> 2. vswitch_port: Any physical or virtio device that is added to
>>> vswitch. The
>>> port can have its own tx/rx functions for doing data transfer, which
>>> are exposed
>>> to the framework using generic function pointers
>>> (vs_port->do_tx/do_rx). This way
>>> the generic code can do tx/rx without understanding the type of device
>>> (Physical or
>>> virtio). Similarly each port has its own functions to select tx/rx
>>> queues. The framework
>>> provides default tx/rx queue selection functions to the port when port
>>> is added
>>> (for both physical and vhost devices). But the framework allows the
>>> switch implementation
>>> to override the queue selection functions (vs_port->get_txq/rxq) if
>>> required.
>>>
>>> 3. vswitch_ops: The ops is set of function pointers which are used to
>>> do operations
>>> like learning, unlearning, add/delete port, lookup_and_forward. The
>>> user of vswitch
>>> framework (vhost/main.[c,h])uses these function pointers to perform
>>> above mentioned
>>> operations, thus it remains agnostic of the underlying implementation.
>>>
>>> Different switching logics can implement their vswitch_device and
>>> vswitch_ops, and
>>> register with the framework. This framework makes vhost-switch
>>> application scalable
>>> in terms of:
>>>
>>> 1. Different switching logics (one of them is vmdq, vhost/vmdq.[c,h]
>>> 2. Number of ports.
>>> 3. Policies of selecting ports for rx and tx.
>>>
>>> Signed-off-by: Pankaj Chauhan
>>
>> After this patch set, how's mapping relationship between cores and
>> vswitch_dev? Old vhost example does not have the concept of switch, so
>> each core is binded with some VDEVs. Now, we still keep original logic?
>>
>> (a) If yes, provided that phys device could has no direct relationship
>> with vdevs in other switching logics, we may need to bind those physical
>> devices to cores too? In that case, switch_worker() will receiving pkts
>> from all devices (phys or virtual) and dispatch, which looks like:
>>
>> switch_worker() {
>> FOR each port binding to this core {
>> rx(port, pkts[], count);
>> vs_lookup_n_fwd( information_needed );
>> }
>> }
>
> Since we support only one switch device running at one time. We bind
> the ports of the switchdev to the core. But The switch might have it's
> own logic to bind the port to the core. For example
> VMDQ only supports one Physical port, other switch can support more
> than one Physical port. In order to take care of that i have added two
> ops in swithdev_ops:
>
> 1. vs_sched_rx_port:
>
> struct vswitch_port *vs_sched_rx_port(struct vswitch_dev *vs_dev, enum
> vswitch_port_type ptype,
> uint16_t core_id)
>
> 2. vs_sched_tx_port:
>
> struct vswitch_port *vs_sched_tx_port(struct vswitch_dev *vs_dev, enum
> vswitch_port_type ptype, uint16_t
> core_id)
>
> The idea of providing these functions is that vhost/main requests the
> underlying switch implementation to schedule a port for rx or Tx, the
> current running core_id is also passed as parameter. So the switch can
> take a decision which port to do rx or tx based on core id, and may be
> some other custom policy.
>
> For example VMDQ always returns the one single Physical port in
> response to these functions called from any core. The other switch
> can return the ports bound to the cores.
>
> Similarly there are two port operations (vs_port->get_rxq and
> vs_port->get_txq), here also we pass core_id as parameter so that
> the underlying switch implementation can schedule the rx or tx queue
> based on the core_id.
>
> The above mentioned ops are used in drain_eth_rx() and
> do_drain_mbuf_table() (main.c) currently, and they leave binding of
> physical port and the queues to the underlying implementation. This
> way we can accommodate VMDQ which uses only one physical port and
> rxqueues based on VMDQ, OR any other switch which uses multiple
> physical port and rx/tx queue scheduling based on some other logic.
>
> Please suggest if this way of scheduling ports and tx/rx queues is
> fine or not?
According to above explanation, in VMDQ switch, we cannot schedule two
queues (belongs to the same port) on the same core, right?
>>
>> (b)
[dpdk-dev] [RFC][PATCH V2 1/3] examples/vhost: Add vswitch (generic switch) framework
On 9/11/2016 5:51 PM, Yuanhan Liu wrote: > On Mon, Sep 05, 2016 at 04:24:29PM +0530, Pankaj Chauhan wrote: >> Introduce support for a generic framework for handling of switching between >> physical and vhost devices. The vswitch framework introduces the following >> concept: >> >> 1. vswitch_dev: Vswitch device is a logical switch which can have physical >> and >> virtio devices. The devices are operated/used using standard rte_eth API for >> physical devices and lib_vhost API for vhost devices, PMD API is not used >> for vhost devices. >> >> 2. vswitch_port: Any physical or virtio device that is added to vswitch. The >> port can have its own tx/rx functions for doing data transfer, which are >> exposed >> to the framework using generic function pointers (vs_port->do_tx/do_rx). >> This way >> the generic code can do tx/rx without understanding the type of device >> (Physical or >> virtio). Similarly each port has its own functions to select tx/rx queues. >> The framework >> provides default tx/rx queue selection functions to the port when port is >> added >> (for both physical and vhost devices). But the framework allows the switch >> implementation >> to override the queue selection functions (vs_port->get_txq/rxq) if required. >> >> 3. vswitch_ops: The ops is set of function pointers which are used to do >> operations >> like learning, unlearning, add/delete port, lookup_and_forward. The user of >> vswitch >> framework (vhost/main.[c,h])uses these function pointers to perform above >> mentioned >> operations, thus it remains agnostic of the underlying implementation. >> >> Different switching logics can implement their vswitch_device and >> vswitch_ops, and >> register with the framework. This framework makes vhost-switch application >> scalable >> in terms of: >> >> 1. Different switching logics (one of them is vmdq, vhost/vmdq.[c,h] >> 2. Number of ports. >> 3. Policies of selecting ports for rx and tx. >> >> Signed-off-by: Pankaj Chauhan > > Hi, > > FYI, my testrobot caught some errors when this patch is applied. > (And sorry for the late review; hopefully I can make it next week). > > --yliu Hi YLiu, Thanks for the review. I am sorry it was my mistake in this patchset, the header defining few structures and macros used in patch 0001 are defined in patch 0003. Because of this 0001 was not individually compilable but all three are compliable as set, it was mistake on my part , will fix it and will take care of it in further patchsets. Do you want me to send another version for review, or i can fix it in the next version i send after review of v2 is complete? Thanks, Pankaj >
[dpdk-dev] [RFC][PATCH V2 1/3] examples/vhost: Add vswitch (generic switch) framework
On 9/9/2016 2:26 PM, Tan, Jianfeng wrote:
> Hi Pankaj,
>
> Thanks for the massive and great work.
Hi Jianfeng,
Thanks for the review.
>
> On 9/5/2016 6:54 PM, Pankaj Chauhan wrote:
>> Introduce support for a generic framework for handling of switching
>> between
>> physical and vhost devices. The vswitch framework introduces the
>> following
>> concept:
>>
>> 1. vswitch_dev: Vswitch device is a logical switch which can have
>> physical and
>> virtio devices. The devices are operated/used using standard rte_eth
>> API for
>> physical devices and lib_vhost API for vhost devices, PMD API is not used
>> for vhost devices.
>>
>> 2. vswitch_port: Any physical or virtio device that is added to
>> vswitch. The
>> port can have its own tx/rx functions for doing data transfer, which
>> are exposed
>> to the framework using generic function pointers
>> (vs_port->do_tx/do_rx). This way
>> the generic code can do tx/rx without understanding the type of device
>> (Physical or
>> virtio). Similarly each port has its own functions to select tx/rx
>> queues. The framework
>> provides default tx/rx queue selection functions to the port when port
>> is added
>> (for both physical and vhost devices). But the framework allows the
>> switch implementation
>> to override the queue selection functions (vs_port->get_txq/rxq) if
>> required.
>>
>> 3. vswitch_ops: The ops is set of function pointers which are used to
>> do operations
>> like learning, unlearning, add/delete port, lookup_and_forward. The
>> user of vswitch
>> framework (vhost/main.[c,h])uses these function pointers to perform
>> above mentioned
>> operations, thus it remains agnostic of the underlying implementation.
>>
>> Different switching logics can implement their vswitch_device and
>> vswitch_ops, and
>> register with the framework. This framework makes vhost-switch
>> application scalable
>> in terms of:
>>
>> 1. Different switching logics (one of them is vmdq, vhost/vmdq.[c,h]
>> 2. Number of ports.
>> 3. Policies of selecting ports for rx and tx.
>>
>> Signed-off-by: Pankaj Chauhan
>
> After this patch set, how's mapping relationship between cores and
> vswitch_dev? Old vhost example does not have the concept of switch, so
> each core is binded with some VDEVs. Now, we still keep original logic?
>
> (a) If yes, provided that phys device could has no direct relationship
> with vdevs in other switching logics, we may need to bind those physical
> devices to cores too? In that case, switch_worker() will receiving pkts
> from all devices (phys or virtual) and dispatch, which looks like:
>
> switch_worker() {
> FOR each port binding to this core {
> rx(port, pkts[], count);
> vs_lookup_n_fwd( information_needed );
> }
> }
Since we support only one switch device running at one time. We bind the
ports of the switchdev to the core. But The switch might have it's own
logic to bind the port to the core. For example
VMDQ only supports one Physical port, other switch can support more than
one Physical port. In order to take care of that i have added two ops in
swithdev_ops:
1. vs_sched_rx_port:
struct vswitch_port *vs_sched_rx_port(struct vswitch_dev *vs_dev, enum
vswitch_port_type ptype, uint16_t
core_id)
2. vs_sched_tx_port:
struct vswitch_port *vs_sched_tx_port(struct vswitch_dev *vs_dev, enum
vswitch_port_type ptype, uint16_t
core_id)
The idea of providing these functions is that vhost/main requests the
underlying switch implementation to schedule a port for rx or Tx, the
current running core_id is also passed as parameter. So the switch can
take a decision which port to do rx or tx based on core id, and may be
some other custom policy.
For example VMDQ always returns the one single Physical port in response
to these functions called from any core. The other switch
can return the ports bound to the cores.
Similarly there are two port operations (vs_port->get_rxq and
vs_port->get_txq), here also we pass core_id as parameter so that
the underlying switch implementation can schedule the rx or tx queue
based on the core_id.
The above mentioned ops are used in drain_eth_rx() and
do_drain_mbuf_table() (main.c) currently, and they leave binding of
physical port and the queues to the underlying implementation. This
way we can accommodate VMDQ which uses only one physical port and
rxqueues based on VMDQ, OR any other switch which uses multiple physical
port and rx/tx queue scheduling based on some other logic.
Please suggest if this way of scheduling ports and tx/rx queues is fine
or not?
>
> (b) If no, we may bind each core with n switches? If so, switch_worker()
> also need to be reworked to keep receiving pkts from all ports of the
> switch, and dispatch.
>
> switch_worker() {
> FOR each switch binding to this core {
> FOR each port of switch {
> rx(port, pkts[], count);
> vs_lookup_n_fwd(
[dpdk-dev] [RFC][PATCH V2 1/3] examples/vhost: Add vswitch (generic switch) framework
On Mon, Sep 05, 2016 at 04:24:29PM +0530, Pankaj Chauhan wrote: > Introduce support for a generic framework for handling of switching between > physical and vhost devices. The vswitch framework introduces the following > concept: > > 1. vswitch_dev: Vswitch device is a logical switch which can have physical and > virtio devices. The devices are operated/used using standard rte_eth API for > physical devices and lib_vhost API for vhost devices, PMD API is not used > for vhost devices. > > 2. vswitch_port: Any physical or virtio device that is added to vswitch. The > port can have its own tx/rx functions for doing data transfer, which are > exposed > to the framework using generic function pointers (vs_port->do_tx/do_rx). This > way > the generic code can do tx/rx without understanding the type of device > (Physical or > virtio). Similarly each port has its own functions to select tx/rx queues. > The framework > provides default tx/rx queue selection functions to the port when port is > added > (for both physical and vhost devices). But the framework allows the switch > implementation > to override the queue selection functions (vs_port->get_txq/rxq) if required. > > 3. vswitch_ops: The ops is set of function pointers which are used to do > operations > like learning, unlearning, add/delete port, lookup_and_forward. The user of > vswitch > framework (vhost/main.[c,h])uses these function pointers to perform above > mentioned > operations, thus it remains agnostic of the underlying implementation. > > Different switching logics can implement their vswitch_device and > vswitch_ops, and > register with the framework. This framework makes vhost-switch application > scalable > in terms of: > > 1. Different switching logics (one of them is vmdq, vhost/vmdq.[c,h] > 2. Number of ports. > 3. Policies of selecting ports for rx and tx. > > Signed-off-by: Pankaj Chauhan Hi, FYI, my testrobot caught some errors when this patch is applied. (And sorry for the late review; hopefully I can make it next week). --yliu --- examples/vhost/main.c: In function 'virtio_xmit': examples/vhost/main.c:815:41: error: 'struct vhost_dev' has no member named 'vs_port' struct vswitch_port *vs_port = dst_vdev->vs_port; ^ examples/vhost/main.c:822:15: error: dereferencing pointer to incomplete type 'struct vswitch_port' txq = vs_port->get_txq(vs_port, rte_lcore_id()); ^ examples/vhost/main.c: In function 'do_drain_mbuf_table': examples/vhost/main.c:952:12: error: implicit declaration of function 'vs_sched_tx_port' [-Werror=implicit-function-declaration] tx_port = vs_sched_tx_port(vswitch_dev_g, VSWITCH_PTYPE_PHYS, ^ examples/vhost/main.c:952:2: error: nested extern declaration of 'vs_sched_tx_port' [-Werror=nested-externs] tx_port = vs_sched_tx_port(vswitch_dev_g, VSWITCH_PTYPE_PHYS, ^ examples/vhost/main.c:952:29: error: 'vswitch_dev_g' undeclared (first use in this function) tx_port = vs_sched_tx_port(vswitch_dev_g, VSWITCH_PTYPE_PHYS, ^ examples/vhost/main.c:952:29: note: each undeclared identifier is reported only once for each function it appears in examples/vhost/main.c:952:44: error: 'VSWITCH_PTYPE_PHYS' undeclared (first use in this function) tx_port = vs_sched_tx_port(vswitch_dev_g, VSWITCH_PTYPE_PHYS, ^ examples/vhost/main.c:958:18: error: dereferencing pointer to incomplete type 'struct vswitch_port' count = tx_port->do_tx(tx_port, tx_q->txq_id, NULL, tx_q->m_table, ^ examples/vhost/main.c:955:6: error: label 'out' used but not defined goto out; ^ examples/vhost/main.c: In function 'drain_eth_rx': examples/vhost/main.c:1096:12: error: implicit declaration of function 'vs_sched_rx_port' [-Werror=implicit-function-declaration] rx_port = vs_sched_rx_port(vswitch_dev_g, VSWITCH_PTYPE_PHYS, ^ examples/vhost/main.c:1096:2: error: nested extern declaration of 'vs_sched_rx_port' [-Werror=nested-externs] rx_port = vs_sched_rx_port(vswitch_dev_g, VSWITCH_PTYPE_PHYS, ^ examples/vhost/main.c:1096:29: error: 'vswitch_dev_g' undeclared (first use in this function) rx_port = vs_sched_rx_port(vswitch_dev_g, VSWITCH_PTYPE_PHYS, ^ examples/vhost/main.c:1096:44: error: 'VSWITCH_PTYPE_PHYS' undeclared (first use in this function) rx_port = vs_sched_rx_port(vswitch_dev_g, VSWITCH_PTYPE_PHYS, ^ examples/vhost/main.c:1105:15: error: dereferencing pointer to incomplete type 'struct vswitch_port' rxq = rx_port->get_rxq(rx_port, vdev, core_id); ^ examples/vhost/main.c:1099:6: error: label 'out' used but not defined goto out; ^ examples/vhost/main.c: In function 'drain_virtio_tx': examples/vhost/main.c:1145:37: error: 'struct vhost_dev' has no member named 'vs_port' struct vswitch_port *vs_port =
[dpdk-dev] [RFC][PATCH V2 1/3] examples/vhost: Add vswitch (generic switch) framework
Hi Pankaj,
Thanks for the massive and great work.
On 9/5/2016 6:54 PM, Pankaj Chauhan wrote:
> Introduce support for a generic framework for handling of switching between
> physical and vhost devices. The vswitch framework introduces the following
> concept:
>
> 1. vswitch_dev: Vswitch device is a logical switch which can have physical and
> virtio devices. The devices are operated/used using standard rte_eth API for
> physical devices and lib_vhost API for vhost devices, PMD API is not used
> for vhost devices.
>
> 2. vswitch_port: Any physical or virtio device that is added to vswitch. The
> port can have its own tx/rx functions for doing data transfer, which are
> exposed
> to the framework using generic function pointers (vs_port->do_tx/do_rx). This
> way
> the generic code can do tx/rx without understanding the type of device
> (Physical or
> virtio). Similarly each port has its own functions to select tx/rx queues.
> The framework
> provides default tx/rx queue selection functions to the port when port is
> added
> (for both physical and vhost devices). But the framework allows the switch
> implementation
> to override the queue selection functions (vs_port->get_txq/rxq) if required.
>
> 3. vswitch_ops: The ops is set of function pointers which are used to do
> operations
> like learning, unlearning, add/delete port, lookup_and_forward. The user of
> vswitch
> framework (vhost/main.[c,h])uses these function pointers to perform above
> mentioned
> operations, thus it remains agnostic of the underlying implementation.
>
> Different switching logics can implement their vswitch_device and
> vswitch_ops, and
> register with the framework. This framework makes vhost-switch application
> scalable
> in terms of:
>
> 1. Different switching logics (one of them is vmdq, vhost/vmdq.[c,h]
> 2. Number of ports.
> 3. Policies of selecting ports for rx and tx.
>
> Signed-off-by: Pankaj Chauhan
After this patch set, how's mapping relationship between cores and
vswitch_dev? Old vhost example does not have the concept of switch, so
each core is binded with some VDEVs. Now, we still keep original logic?
(a) If yes, provided that phys device could has no direct relationship
with vdevs in other switching logics, we may need to bind those physical
devices to cores too? In that case, switch_worker() will receiving pkts
from all devices (phys or virtual) and dispatch, which looks like:
switch_worker() {
FOR each port binding to this core {
rx(port, pkts[], count);
vs_lookup_n_fwd( information_needed );
}
}
(b) If no, we may bind each core with n switches? If so, switch_worker()
also need to be reworked to keep receiving pkts from all ports of the
switch, and dispatch.
switch_worker() {
FOR each switch binding to this core {
FOR each port of switch {
rx(port, pkts[], count);
vs_lookup_n_fwd( information_needed );
}
}
}
In all, (1) we'd better not use vdev to find phys dev in switch_worker
any more; (2) we'd better not differentiate phys device and virtual
device in generic framework (it's just an attribute of vswitch_port.
What do you think?
Thanks,
Jianfeng
[dpdk-dev] [RFC][PATCH V2 1/3] examples/vhost: Add vswitch (generic switch) framework
Introduce support for a generic framework for handling of switching between
physical and vhost devices. The vswitch framework introduces the following
concept:
1. vswitch_dev: Vswitch device is a logical switch which can have physical and
virtio devices. The devices are operated/used using standard rte_eth API for
physical devices and lib_vhost API for vhost devices, PMD API is not used
for vhost devices.
2. vswitch_port: Any physical or virtio device that is added to vswitch. The
port can have its own tx/rx functions for doing data transfer, which are exposed
to the framework using generic function pointers (vs_port->do_tx/do_rx). This
way
the generic code can do tx/rx without understanding the type of device
(Physical or
virtio). Similarly each port has its own functions to select tx/rx queues. The
framework
provides default tx/rx queue selection functions to the port when port is added
(for both physical and vhost devices). But the framework allows the switch
implementation
to override the queue selection functions (vs_port->get_txq/rxq) if required.
3. vswitch_ops: The ops is set of function pointers which are used to do
operations
like learning, unlearning, add/delete port, lookup_and_forward. The user of
vswitch
framework (vhost/main.[c,h])uses these function pointers to perform above
mentioned
operations, thus it remains agnostic of the underlying implementation.
Different switching logics can implement their vswitch_device and vswitch_ops,
and
register with the framework. This framework makes vhost-switch application
scalable
in terms of:
1. Different switching logics (one of them is vmdq, vhost/vmdq.[c,h]
2. Number of ports.
3. Policies of selecting ports for rx and tx.
Signed-off-by: Pankaj Chauhan
---
examples/vhost/Makefile | 2 +-
examples/vhost/main.c | 128 +--
examples/vhost/vswitch_common.c | 499
examples/vhost/vswitch_common.h | 186 +++
examples/vhost/vswitch_txrx.c | 97
examples/vhost/vswitch_txrx.h | 71 ++
6 files changed, 966 insertions(+), 17 deletions(-)
create mode 100644 examples/vhost/vswitch_common.c
create mode 100644 examples/vhost/vswitch_common.h
create mode 100644 examples/vhost/vswitch_txrx.c
create mode 100644 examples/vhost/vswitch_txrx.h
diff --git a/examples/vhost/Makefile b/examples/vhost/Makefile
index e95c68a..1b58308 100644
--- a/examples/vhost/Makefile
+++ b/examples/vhost/Makefile
@@ -48,7 +48,7 @@ else
APP = vhost-switch
# all source are stored in SRCS-y
-SRCS-y := main.c
+SRCS-y := main.c vswitch_common.c vswitch_txrx.c vmdq.c
CFLAGS += -O2 -D_FILE_OFFSET_BITS=64
CFLAGS += $(WERROR_FLAGS)
diff --git a/examples/vhost/main.c b/examples/vhost/main.c
index 92a9823..c949df4 100644
--- a/examples/vhost/main.c
+++ b/examples/vhost/main.c
@@ -811,9 +811,16 @@ static inline void __attribute__((always_inline))
virtio_xmit(struct vhost_dev *dst_vdev, struct vhost_dev *src_vdev,
struct rte_mbuf *m)
{
- uint16_t ret;
+ uint16_t ret, txq;
+ struct vswitch_port *vs_port = dst_vdev->vs_port;
- ret = rte_vhost_enqueue_burst(dst_vdev->vid, VIRTIO_RXQ, , 1);
+ /* The switch implmentation decides the txq for each port itself.
+* this gives switch implmentations to choose thier own queue management
+* for each port
+*/
+
+ txq = vs_port->get_txq(vs_port, rte_lcore_id());
+ ret = rte_vhost_enqueue_burst(dst_vdev->vid, txq, , 1);
if (enable_stats) {
rte_atomic64_inc(_vdev->stats.rx_total_atomic);
rte_atomic64_add(_vdev->stats.rx_atomic, ret);
@@ -832,7 +839,7 @@ virtio_tx_local(struct vhost_dev *vdev, struct rte_mbuf *m)
struct ether_hdr *pkt_hdr;
struct vhost_dev *dst_vdev;
- pkt_hdr = rte_pktmbuf_mtod(m, struct ether_hdr *);
+ pkt_hdr = rte_pktmbuf_mtod(m, struct ether_hdr *);
dst_vdev = find_vhost_dev(_hdr->d_addr);
if (!dst_vdev)
@@ -934,11 +941,26 @@ static inline void __attribute__((always_inline))
do_drain_mbuf_table(struct mbuf_table *tx_q)
{
uint16_t count;
+ struct vswitch_port *tx_port;
+
+ /* Let switch implmentation decide which physical port to do tx to.
+* Every switch implmentation may have it's own strategy, for example
+* VMDQ does tx to only one Physical port. Having a scheduler function
+* which is switch specefic give flexibility to have another strategy
+* for a switch
+*/
+ tx_port = vs_sched_tx_port(vswitch_dev_g, VSWITCH_PTYPE_PHYS,
+rte_lcore_id());
+ if (unlikely(!tx_port))
+ goto out;
- count = rte_eth_tx_burst(ports[0], tx_q->txq_id,
-tx_q->m_table, tx_q->len);
- if (unlikely(count < tx_q->len))
- free_pkts(_q->m_table[count], tx_q->len - count);
+ if (tx_q->len) {
+
