[dpdk-dev] [PATCH v7 4/8] vhost: rxtx: use queue id instead of constant ring index
On Thu, Oct 22, 2015 at 02:32:31PM +0300, Michael S. Tsirkin wrote: > On Thu, Oct 22, 2015 at 05:49:55PM +0800, Yuanhan Liu wrote: > > On Wed, Oct 21, 2015 at 05:26:18PM +0300, Michael S. Tsirkin wrote: > > > On Wed, Oct 21, 2015 at 08:48:15PM +0800, Yuanhan Liu wrote: > > > > > Please note that for virtio devices, guest is supposed to > > > > > control the placement of incoming packets in RX queues. > > > > > > > > I may not follow you. > > > > > > > > Enqueuing packets to a RX queue is done at vhost lib, outside the > > > > guest, how could the guest take the control here? > > > > > > > > --yliu > > > > > > vhost should do what guest told it to. > > > > > > See virtio spec: > > > 5.1.6.5.5 Automatic receive steering in multiqueue mode > > > > Spec says: > > > > After the driver transmitted a packet of a flow on transmitqX, > > the device SHOULD cause incoming packets for that flow to be > > steered to receiveqX. > > > > > > Michael, I still have no idea how vhost could know the flow even > > after discussion with Huawei. Could you be more specific about > > this? Say, how could guest know that? And how could guest tell > > vhost which RX is gonna to use? > > > > Thanks. > > > > --yliu > > I don't really understand the question. > > When guests transmits a packet, it makes a decision > about the flow to use, and maps that to a tx/rx pair of queues. > > It sends packets out on the tx queue and expects device to > return packets from the same flow on the rx queue. Why? I can understand that there should be a mapping between flows and queues in a way that there is no re-ordering, but I can't see the relation of receiving a flow with a TX queue. fbl > During transmit, device needs to figure out the flow > of packets as they are received from guest, and track > which flows go on which tx queue. > When it selects the rx queue, it has to use the same table. > > There is currently no provision for controlling > steering for uni-directional > flows which are possible e.g. with UDP. > > We might solve this in a future spec - for example, set a flag notifying > guest that steering information is missing for a given flow, for example > by setting a flag in a packet, or using the command queue, and have > guest send a dummy empty packet to set steering rule for this flow. > > > -- > MST >
[dpdk-dev] [PATCH 3/5] bnx2x: Add RTE_LIBRTE_BNX2X_REG_ACCESS config option
2015-10-23 22:28, Harish Patil: > >2015-09-11 17:42, Rasesh Mody: > >> From: Harish Patil > >> --- a/config/common_linuxapp > >> +++ b/config/common_linuxapp > >> @@ -220,6 +220,7 @@ CONFIG_RTE_LIBRTE_BNX2X_DEBUG_INIT=n > >> CONFIG_RTE_LIBRTE_BNX2X_DEBUG_RX=n > >> CONFIG_RTE_LIBRTE_BNX2X_DEBUG_TX=n > >> CONFIG_RTE_LIBRTE_BNX2X_MF_SUPPORT=n > >> +CONFIG_RTE_LIBRTE_BNX2X_REG_ACCESS=n > > > >Why do you need this option? > > Currently logging of register accesses is using (wrongly) the generic > driver debug option of PMD_DRV_LOG (which gets enabled if > CONFIG_RTE_LIBRTE_BNX2X_DEBUG=y). > This floods the console due to excessive printing of register > reads/writes. So creating a new debug option in order to capture only the > register read/writes (if required) and also does not interfere with the > informational/user-level debug. You mean there is not enough log levels? #define RTE_LOG_EMERG1U /**< System is unusable. */ #define RTE_LOG_ALERT2U /**< Action must be taken immediately. */ #define RTE_LOG_CRIT 3U /**< Critical conditions. */ #define RTE_LOG_ERR 4U /**< Error conditions. */ #define RTE_LOG_WARNING 5U /**< Warning conditions. */ #define RTE_LOG_NOTICE 6U /**< Normal but significant condition. */ #define RTE_LOG_INFO 7U /**< Informational.*/ #define RTE_LOG_DEBUG8U /**< Debug-level messages. */ Either other "debug" logs can be put as INFO level, or you need a level 9 for verbose debug. But I don't really understand what is the problem of a verbose debug. It is not critical for the acceptance of this patch. Just wanted to discuss it as we have many config options to tune the debug. Please, at least, use the DEBUG word in the option name as done for CONFIG_RTE_LIBRTE_BNX2X_DEBUG_RX.
[dpdk-dev] [PATCH] testpmd: modify the mac of csum forwarding
2015-10-13 06:29, Qiu, Michael: > Hi, Thomas > > Any comments on this patch? Is it suitable for DPDK? Please check with the testpmd maintainer. Pablo?
[dpdk-dev] [PATCH] vchost: Notify application of ownership change
2015-08-12 03:34, Xie, Huawei: > On 8/8/2015 1:21 AM, Jan Kiszka wrote: > > On VHOST_*_RESET_OWNER, we reinitialize the device but without telling > > the application. That will cause crashes when it continues to invoke > > vhost services on the device. Fix it by calling the destruction hook if > > the device is still in use. [...] > > --- a/lib/librte_vhost/virtio-net.c > > +++ b/lib/librte_vhost/virtio-net.c > > @@ -402,6 +402,9 @@ reset_owner(struct vhost_device_ctx ctx) > > > > ll_dev = get_config_ll_entry(ctx); > > > > + if ((ll_dev->dev.flags & VIRTIO_DEV_RUNNING)) > > + notify_ops->destroy_device(&ll_dev->dev); > > To me this patch makes sense here. > Whether RESET_OWNER is really needed is another question. Whenever the > vhost itself needs to process the vhost device, we need to notify the > switch application to remove it from data plane. Huawei, some patches have been accepted for RESET_OWNER management. Is this patch obsolete?
[dpdk-dev] [PATCH v1] Return ENOMEM during mpipe_devinit failure
> >In function rte_pmd_mpipe_devinit, if rte_eth_dev_allocate > >fails return error which is inline with other drivers. > > > >Signed-off-by: Ravi Kerur > > Thanks for fixing this. > Acked-by: Zhigang Lu Applied, thanks
[dpdk-dev] [PATCH v7 4/8] vhost: rxtx: use queue id instead of constant ring index
On Sat, Oct 24, 2015 at 12:34:08AM -0200, Flavio Leitner wrote: > On Thu, Oct 22, 2015 at 02:32:31PM +0300, Michael S. Tsirkin wrote: > > On Thu, Oct 22, 2015 at 05:49:55PM +0800, Yuanhan Liu wrote: > > > On Wed, Oct 21, 2015 at 05:26:18PM +0300, Michael S. Tsirkin wrote: > > > > On Wed, Oct 21, 2015 at 08:48:15PM +0800, Yuanhan Liu wrote: > > > > > > Please note that for virtio devices, guest is supposed to > > > > > > control the placement of incoming packets in RX queues. > > > > > > > > > > I may not follow you. > > > > > > > > > > Enqueuing packets to a RX queue is done at vhost lib, outside the > > > > > guest, how could the guest take the control here? > > > > > > > > > > --yliu > > > > > > > > vhost should do what guest told it to. > > > > > > > > See virtio spec: > > > > 5.1.6.5.5 Automatic receive steering in multiqueue mode > > > > > > Spec says: > > > > > > After the driver transmitted a packet of a flow on transmitqX, > > > the device SHOULD cause incoming packets for that flow to be > > > steered to receiveqX. > > > > > > > > > Michael, I still have no idea how vhost could know the flow even > > > after discussion with Huawei. Could you be more specific about > > > this? Say, how could guest know that? And how could guest tell > > > vhost which RX is gonna to use? > > > > > > Thanks. > > > > > > --yliu > > > > I don't really understand the question. > > > > When guests transmits a packet, it makes a decision > > about the flow to use, and maps that to a tx/rx pair of queues. > > > > It sends packets out on the tx queue and expects device to > > return packets from the same flow on the rx queue. > > Why? I can understand that there should be a mapping between > flows and queues in a way that there is no re-ordering, but > I can't see the relation of receiving a flow with a TX queue. > > fbl That's the way virtio chose to program the rx steering logic. It's low overhead (no special commands), and works well for TCP when user is an endpoint since rx and tx for tcp are generally tied (because of ack handling). We can discuss other ways, e.g. special commands for guests to program steering. We'd have to first see some data showing the current scheme is problematic somehow. > > During transmit, device needs to figure out the flow > > of packets as they are received from guest, and track > > which flows go on which tx queue. > > When it selects the rx queue, it has to use the same table. > > > > There is currently no provision for controlling > > steering for uni-directional > > flows which are possible e.g. with UDP. > > > > We might solve this in a future spec - for example, set a flag notifying > > guest that steering information is missing for a given flow, for example > > by setting a flag in a packet, or using the command queue, and have > > guest send a dummy empty packet to set steering rule for this flow. > > > > > > -- > > MST > >
[dpdk-dev] [PATCH] app/test-pmd: Detect NUMA socket count
> > Currently, there is a MAX_SOCKET macro which artificially limits the > > number of NUMA sockets testpmd can use. Anything on a higher socket > > ends up using socket zero. This patch replaces this with a variable > > set during set_default_fwd_lcores_config() and uses > > RTE_MAX_NUMA_NODES > > where a hard-coded max number of sockets is required. > > > > Signed-off-by: Stephen Hurd > > Acked-by: Pablo de Lara Applied, thanks
[dpdk-dev] [PATCH] librte_eal: Fix wrong header file for old gcc version
Please submit a v2 with complete git message including compiler error, Fixes and Acked-by tags. Thanks 2015-10-13 09:54, Bruce Richardson: > On Mon, Aug 24, 2015 at 05:22:57PM +0800, Michael Qiu wrote: > > For __SSE3__, the corresponding header file should be pmmintrin.h, > > tmmintrin.h works for __SSSE3__. > > > > Signed-off-by: Michael Qiu > > Since this is a bug-fix, it should probably have a fixes line in the commit. > Otherwise the change looks ok. > > Acked-by: Bruce Richardson
[dpdk-dev] [PATCH] acl: Improve acl_bld.c sort_rules()
> > Replace O(n^2) list sort with an O(n log n) merge sort. > > The merge sort is based on the solution suggested in: > > http://cslibrary.stanford.edu/105/LinkedListProblems.pdf > > Tested sort_rules() improvement: > > 100K rules: O(n^2): 31382 milliseconds; O(n log n): 10 milliseconds > > 259K rules: O(n^2): 133753 milliseconds; O(n log n): 22 milliseconds > > > > Signed-off-by: Mark Smith > > Acked-by: Konstantin Ananyev Applied, thanks
[dpdk-dev] [PATCH] app/testpmd: add engine for UDP echo server support
Pablo, opinion? Is the UDP echo eligible in testpmd to ease some tests? 2015-09-04 14:17, Thadeu Lima de Souza Cascardo: > Adapt the ICMP echo code to reply to UDP echo requests on port 7. The testpmd > forward engine udpecho is used for that. > > Signed-off-by: Thadeu Lima de Souza Cascardo
