[dpdk-dev] [PATCH v2] doc: announce ABI change for rte_eth_dev structure
On Wed, Jul 27, 2016 at 01:59:01AM -0700, Thomas Monjalon wrote: > > > Signed-off-by: Tomasz Kulasek > > > --- > > > +* In 16.11 ABI changes are plained: the ``rte_eth_dev`` structure will be > > > + extended with new function pointer ``tx_pkt_prep`` allowing > > > verification > > > + and processing of packet burst to meet HW specific requirements before > > > + transmit. Also new fields will be added to the ``rte_eth_desc_lim`` > > > structure: > > > + ``nb_seg_max`` and ``nb_mtu_seg_max`` provideing information about > > > number of > > > + segments limit to be transmitted by device for TSO/non-TSO packets. > > > > Acked-by: Konstantin Ananyev > > I think I understand you want to split the TX processing: > 1/ modify/write in mbufs > 2/ write in HW > and let application decide: > - where the TX prep is done (which core) In what basics applications knows when and where to call tx_pkt_prep in fast path. if all the time it needs to call before tx_burst then the PMD won't have/don't need this callback waste cycles in fast path.Is this the expected behavior ? Anything think it as compile time to make other PMDs wont suffer because of this change. > - what to do if the TX prep fail > So adding some processing in this first part becomes "not too expensive" or > "manageable" from the application point of view. > > If I well understand the intent, > > Acked-by: Thomas Monjalon > (except typos ;)
[dpdk-dev] ACL: BUG: rte_acl_classify_scalar mismatch when usea special rule
sorry, i make a mistake when set the rte_acl_field_def.
the input_index is not consecutive when define sport/dport like this:
{
.type = RTE_ACL_FIELD_TYPE_RANGE,
.size = sizeof(uint16_t),
.field_index = SRCP_FIELD_IPV4,
.input_index = RTE_ACL_IPV4_SPORT,
.offset = sizeof(struct ipv4_hdr) -
offsetof(struct ipv4_hdr, next_proto_id),
},
{
.type = RTE_ACL_FIELD_TYPE_RANGE,
.size = sizeof(uint16_t),
.field_index = DSTP_FIELD_IPV4,
.input_index = RTE_ACL_IPV4_DPORT,
.offset = sizeof(struct ipv4_hdr) -
offsetof(struct ipv4_hdr, next_proto_id) +
sizeof(uint16_t),
},
input_index RTE_ACL_IPV4_SPORT is not equal to RTE_ACL_IPV4_DPORT, and size is
uint16_t not 4 consecutive bytes.
in program guide, it has a instruction as following:
[input_index As mentioned above, all input fields, except the very first one,
must be in groups of 4 consecutive bytes. The input index specifies to which
input group that field belongs to.]
change rte_acl_field_def as following, then match ok:
{
.type = RTE_ACL_FIELD_TYPE_RANGE,
.size = sizeof(uint16_t),
.field_index = SRCP_FIELD_IPV4,
.input_index = RTE_ACL_IPV4_PORT,
.offset = sizeof(struct ipv4_hdr) -
offsetof(struct ipv4_hdr, next_proto_id),
},
{
.type = RTE_ACL_FIELD_TYPE_RANGE,
.size = sizeof(uint16_t),
.field_index = DSTP_FIELD_IPV4,
.input_index = RTE_ACL_IPV4_PORT,
.offset = sizeof(struct ipv4_hdr) -
offsetof(struct ipv4_hdr, next_proto_id) +
sizeof(uint16_t),
},
emr, read the code of ACL lib again, especially acl_calc_wildness and
acl_rule_stats functions, full of trick!
-- Original --
From: "Ananyev, Konstantin";;
Send time: Wednesday, Jul 27, 2016 7:31 PM
To: "??"; "dev";
Subject: RE: [dpdk-dev] ACL: BUG: rte_acl_classify_scalar mismatch when usea
special rule
Hi,
>
> define a rule as following:
>
> struct acl_ipv4_rule acl_rule[] = {
> {
> .data = {.userdata = 103, .category_mask = 1, .priority = 1},
> /* proto */
> .field[0] = {.value.u8 = 0, .mask_range.u8 = 0x0,},
> /* source IPv4 */
> .field[1] = {.value.u32 = IPv4(0, 0, 0, 0), .mask_range.u32 = 0,},
> /* destination IPv4 */
> .field[2] = {.value.u32 = IPv4(192, 168, 2, 4), .mask_range.u32 =
> 32,},
> /* source port */
> .field[3] = {.value.u16 = 0, .mask_range.u16 = 0x,},
> /* destination port */
> .field[4] = {.value.u16 = 1024, .mask_range.u16 = 0x,},
> },
> };
>
> build a pkt like this:
>
> pv4_hdr->next_proto_id = 6;
> ipv4_hdr->src_addr = rte_cpu_to_be_32(IPv4(10, 18, 2, 3));
> ipv4_hdr->dst_addr = rte_cpu_to_be_32(IPv4(192, 168, 2, 4));
> port = (uint16_t*)((unsigned char*)ipv4_hdr + sizeof(struct ipv4_hdr));
> port[0] = rte_cpu_to_be_16();
> port[1] = rte_cpu_to_be_16(4608);
>
> rte_acl_classify_scalar will mismatch this packet!
>
> i readed rte_acl_classify_scalar function, and found the reason:
>
> while (flows.started > 0) {
>
> input0 = GET_NEXT_4BYTES(parms, 0);
> input1 = GET_NEXT_4BYTES(parms, 1);
>
> for (n = 0; n < 4; n++) {
>
> transition0 = scalar_transition(flows.trans,
> transition0, (uint8_t)input0);
> input0 >>= CHAR_BIT;
>
> transition1 = scalar_transition(flows.trans,
> transition1, (uint8_t)input1);
> input1 >>= CHAR_BIT;
> }
>
> while ((transition0 | transition1) & RTE_ACL_NODE_MATCH) {
> transition0 = acl_match_check(transition0,
> 0, ctx, parms, , resolve_priority_scalar);
> transition1 = acl_match_check(transition1,
> 1, ctx, parms, , resolve_priority_scalar);
> }
> }
>
> everytime, scalar get 4bytes to transition, and usually it work well, but if
> we set a acl rule as prior, mismatch will appear.
> this is because field[3] is a 100% wild node, so it was removed as a
> deactivated field.
>
> in this situation, when rte_acl_classify_scalar runs, proto/sip/dip match ok,
> and then it skip sport because it was removed.
> now input0 is a int value(4 bytes) started form dport.
> it will get a match-node after 2 bytes match(dport is a short value), but
> cycle stoped untill n = 4, finally it translated to another node which is
> not a match-node, the mismatch happened.
>
> i'm not sure search_sse_8/search_sse_4/search_avx2x16 is Ok.
>
> how to fix it?
> i think set GET_NEXT_4BYTES to GET_NEXT_BYTE will solve this problem, but it
> will influence performance.
> another way, don't use acl_rule_stats to remove deactivated field, but code
> will change a lot.
If you believe there is a problem, could you try to
[dpdk-dev] doc: announce ivshmem support removal
On Wed, 20 Jul 2016 18:35:46 +0200 Thomas Monjalon wrote: > There was a prior call with an explanation of what needs to be done: > http://dpdk.org/ml/archives/dev/2016-June/040844.html > - Qemu patch upstreamed > - IVSHMEM PCI device managed by a PCI driver > - No DPDK objects (ring/mempool) allocated by EAL > > As nobody seems interested, it is time to remove this code which > makes EAL improvements harder. > > Signed-off-by: Thomas Monjalon > Acked-by: David Marchand > Acked-by: Maxime Coquelin Acked-by: Jan Viktorin
[dpdk-dev] doc: deprecate vhost-cuse
On Fri, 15 Jul 2016 20:28:33 +0800 Yuanhan Liu wrote: > Vhost-cuse was invented before vhost-user exist. The both are actually > doing the same thing: a vhost-net implementation in user space. But they > are not exactly the same thing. > > Firstly, vhost-cuse is harder for use; no one seems to care it, either. > Furthermore, since v2.1, a large majority of development effort has gone > to vhost-user. For example, we extended the vhost-user spec to add the > multiple queue support. We also added the vhost-user live migration at > v16.04 and the latest one, vhost-user reconnect that allows vhost app > restart without restarting the guest. Both of them are very important > features for product usage and none of them works for vhost-cuse. > > You now see that the difference between vhost-user and vhost-cuse is > big (and will be bigger and bigger as time moves forward), that you > should never use vhost-cuse, that we should drop it completely. > > The remove would also result to a much cleaner code base, allowing us > to do all kinds of extending easier. > > So here to mark vhost-cuse as deprecated in this release and will be > removed in the next release (v16.11). > > Signed-off-by: Yuanhan Liu > Acked-by: Ciara Loftus > Acked-by: Thomas Monjalon > Acked-by: Rich Lane Acked-by: Jan Viktorin
[dpdk-dev] [PATCH v2] doc: announce ABI change for rte_eth_dev structure
> > On Wed, Jul 27, 2016 at 05:33:01PM +, Ananyev, Konstantin wrote: > > > > > > > -Original Message- > > > From: Jerin Jacob [mailto:jerin.jacob at caviumnetworks.com] > > > Sent: Wednesday, July 27, 2016 6:11 PM > > > To: Thomas Monjalon > > > Cc: Kulasek, TomaszX ; dev at dpdk.org; > > > Ananyev, Konstantin > > > Subject: Re: [dpdk-dev] [PATCH v2] doc: announce ABI change for > > > rte_eth_dev structure > > > > > > On Wed, Jul 27, 2016 at 01:59:01AM -0700, Thomas Monjalon wrote: > > > > > > Signed-off-by: Tomasz Kulasek > > > > > > --- > > > > > > +* In 16.11 ABI changes are plained: the ``rte_eth_dev`` > > > > > > +structure will be > > > > > > + extended with new function pointer ``tx_pkt_prep`` allowing > > > > > > +verification > > > > > > + and processing of packet burst to meet HW specific > > > > > > +requirements before > > > > > > + transmit. Also new fields will be added to the > > > > > > ``rte_eth_desc_lim`` structure: > > > > > > + ``nb_seg_max`` and ``nb_mtu_seg_max`` provideing > > > > > > +information about number of > > > > > > + segments limit to be transmitted by device for TSO/non-TSO > > > > > > packets. > > > > > > > > > > Acked-by: Konstantin Ananyev > > > > > > > > I think I understand you want to split the TX processing: > > > > 1/ modify/write in mbufs > > > > 2/ write in HW > > > > and let application decide: > > > > - where the TX prep is done (which core) > > > > > > In what basics applications knows when and where to call tx_pkt_prep in > > > fast path. > > > if all the time it needs to call before tx_burst then the PMD won't > > > have/don't need this callback waste cycles in fast path.Is this the > > > expected behavior ? > > > Anything think it as compile time to make other PMDs wont suffer because > > > of this change. > > > > Not sure what suffering you are talking about... > > Current model - i.e. when application does preparations (or doesn't if > > none is required) on its own and just call tx_burst() would still be there. > > If the app doesn't want to use tx_prep() by some reason - that still > > ok, and decision is up to the particular app. > > So my question is in what basics application decides to call the preparation. > Can you tell me the use case in application perspective? I suppose one most common use-case when application uses HW TX offloads, and don't' to cope on its own which L3/L4 header fields need to be filled for that particular dev_type/hw_offload combination. Instead it just setups the ol_flags, fills tx_offload fields and calls tx_prep(). Please read the original Tomasz's patch, I think he explained possible use-cases with lot of details. > and what if the PMD does not implement that callback then it is of waste > cycles. Right? If you refer as lost cycles here something like: RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->tx_prep, -ENOTSUP); then yes. Though comparing to actual work need to be done for most HW TX offloads, I think it is neglectable. Again, as I said before, it is totally voluntary for the application. Konstantin > > Jerin > > > > Konstantin > > > > > > > > > > > > - what to do if the TX prep fail > > > > So adding some processing in this first part becomes "not too > > > > expensive" or "manageable" from the application point of view. > > > > > > > > If I well understand the intent, > > > > > > > > Acked-by: Thomas Monjalon (except > > > > typos ;)
[dpdk-dev] [PATCH v3 4/4] eal: fix end character check in --lcores argument
With --lcores 'a-b at c-d', eal_parse_cores() fails because
eal_parse_set() fails due to the next character after
lcore set a-b, which is '@'and not ',' or '\0'.
There is also a right check immediately
after this incorrect check.
Fixes: 53e54bf81700 ("eal: new option --lcores for cpu assignment")
Signed-off-by: Wei Dai
---
lib/librte_eal/common/eal_common_options.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_options.c
b/lib/librte_eal/common/eal_common_options.c
index 1a1bab3..f443a61 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -469,8 +469,6 @@ eal_parse_set(const char *input, uint16_t set[], unsigned
num)
max = idx;
while (isblank(*end))
end++;
- if (*end != ',' && *end != '\0')
- return -1;
}
if (*end != ',' && *end != '\0' &&
--
2.5.5
[dpdk-dev] [PATCH v3 3/4] eal: fix tail blank check in --lcores argument
the tail blank after a group of lcore or cpu set
will make check of its end character fail.
for example: --lcores '(0-3)@(0-3) ,(4-5)@(4-5)',
the next character after cpu set (0-3) is not ','
or '\0', which fail the check in eal_parse_lcores( ).
Fixes: 53e54bf81700 ("eal: new option --lcores for cpu assignment")
Signed-off-by: Wei Dai
---
lib/librte_eal/common/eal_common_options.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/lib/librte_eal/common/eal_common_options.c
b/lib/librte_eal/common/eal_common_options.c
index 217d08b..1a1bab3 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -530,6 +530,13 @@ eal_parse_set(const char *input, uint16_t set[], unsigned
num)
str = end + 1;
} while (*end != '\0' && *end != ')');
+ /*
+* to avoid failure that tail blank makes end character check fail
+* in eal_parse_lcores( )
+*/
+ while (isblank(*str))
+ str++;
+
return str - input;
}
--
2.5.5
[dpdk-dev] [PATCH v3 2/4] eal: fix parsing of eal option --lcores
The '-' in lcore set overrides cpu set of following
lcore set in the argument of EAL option --lcores.
for example --locres '0-2,(3-5)@(3,4),6@(5,6),7@(5-7)',
0-2 make lflags=1 which indeed suppress following
cpu set (3,4), (5,6) and (5-7) after @ .
Fixes: 53e54bf81700 ("eal: new option --lcores for cpu assignment")
Signed-off-by: Wei Dai
---
lib/librte_eal/common/eal_common_options.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/lib/librte_eal/common/eal_common_options.c
b/lib/librte_eal/common/eal_common_options.c
index c5bf98c..217d08b 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -583,7 +583,7 @@ eal_parse_lcores(const char *lcores)
const char *end = NULL;
int offset;
rte_cpuset_t cpuset;
- int lflags = 0;
+ int lflags;
int ret = -1;
if (lcores == NULL)
@@ -609,6 +609,8 @@ eal_parse_lcores(const char *lcores)
if (*lcores == '\0')
goto err;
+ lflags = 0;
+
/* record lcore_set start point */
lcore_start = lcores;
--
2.5.5
[dpdk-dev] [PATCH v3 1/4] eal: remove redundant codes to parse --lcores
local variable i is not referred by other codes in the function eal_parse_lcores( ), so it can be removed. Signed-off-by: Wei Dai --- lib/librte_eal/common/eal_common_options.c | 4 1 file changed, 4 deletions(-) diff --git a/lib/librte_eal/common/eal_common_options.c b/lib/librte_eal/common/eal_common_options.c index 481c732..c5bf98c 100644 --- a/lib/librte_eal/common/eal_common_options.c +++ b/lib/librte_eal/common/eal_common_options.c @@ -578,7 +578,6 @@ eal_parse_lcores(const char *lcores) struct rte_config *cfg = rte_eal_get_configuration(); static uint16_t set[RTE_MAX_LCORE]; unsigned idx = 0; - int i; unsigned count = 0; const char *lcore_start = NULL; const char *end = NULL; @@ -593,9 +592,6 @@ eal_parse_lcores(const char *lcores) /* Remove all blank characters ahead and after */ while (isblank(*lcores)) lcores++; - i = strlen(lcores); - while ((i > 0) && isblank(lcores[i - 1])) - i--; CPU_ZERO(); -- 2.5.5
[dpdk-dev] ACL: BUG: rte_acl_classify_scalar mismatch when use a special rule
define a rule as following:
struct acl_ipv4_rule acl_rule[] = {
{
.data = {.userdata = 103, .category_mask = 1, .priority = 1},
/* proto */
.field[0] = {.value.u8 = 0, .mask_range.u8 = 0x0,},
/* source IPv4 */
.field[1] = {.value.u32 = IPv4(0, 0, 0, 0), .mask_range.u32 = 0,},
/* destination IPv4 */
.field[2] = {.value.u32 = IPv4(192, 168, 2, 4), .mask_range.u32 = 32,},
/* source port */
.field[3] = {.value.u16 = 0, .mask_range.u16 = 0x,},
/* destination port */
.field[4] = {.value.u16 = 1024, .mask_range.u16 = 0x,},
},
};
build a pkt like this:
pv4_hdr->next_proto_id = 6;
ipv4_hdr->src_addr = rte_cpu_to_be_32(IPv4(10, 18, 2, 3));
ipv4_hdr->dst_addr = rte_cpu_to_be_32(IPv4(192, 168, 2, 4));
port = (uint16_t*)((unsigned char*)ipv4_hdr + sizeof(struct ipv4_hdr));
port[0] = rte_cpu_to_be_16();
port[1] = rte_cpu_to_be_16(4608);
rte_acl_classify_scalar will mismatch this packet!
i readed rte_acl_classify_scalar function, and found the reason:
while (flows.started > 0) {
input0 = GET_NEXT_4BYTES(parms, 0);
input1 = GET_NEXT_4BYTES(parms, 1);
for (n = 0; n < 4; n++) {
transition0 = scalar_transition(flows.trans,
transition0, (uint8_t)input0);
input0 >>= CHAR_BIT;
transition1 = scalar_transition(flows.trans,
transition1, (uint8_t)input1);
input1 >>= CHAR_BIT;
}
while ((transition0 | transition1) & RTE_ACL_NODE_MATCH) {
transition0 = acl_match_check(transition0,
0, ctx, parms, , resolve_priority_scalar);
transition1 = acl_match_check(transition1,
1, ctx, parms, , resolve_priority_scalar);
}
}
everytime, scalar get 4bytes to transition, and usually it work well, but if we
set a acl rule as prior, mismatch will appear.
this is because field[3] is a 100% wild node, so it was removed as a
deactivated field.
in this situation, when rte_acl_classify_scalar runs, proto/sip/dip match ok,
and then it skip sport because it was removed.
now input0 is a int value(4 bytes) started form dport.
it will get a match-node after 2 bytes match(dport is a short value), but cycle
stoped untill n = 4, finally it translated to another node which is not a
match-node, the mismatch happened.
i'm not sure search_sse_8/search_sse_4/search_avx2x16 is Ok.
how to fix it?
i think set GET_NEXT_4BYTES to GET_NEXT_BYTE will solve this problem, but it
will influence performance.
another way, don't use acl_rule_stats to remove deactivated field, but code
will change a lot.
[dpdk-dev] doc: announce renaming of ethdev library
On Tue, 26 Jul 2016 18:22:21 +0200 Thomas Monjalon wrote: > The right name of ethdev should be dpdk_netdev. However: > 1/ We are using rte_ prefix in the code and library names. > 2/ The API uses rte_ethdev > That's why 16.11 will just have the rte_ prefix prepended to > the library filename as every other libraries. > > Signed-off-by: Thomas Monjalon > Acked-by: Jan Viktorin
[dpdk-dev] doc: announce ivshmem support removal
On 07/20/2016 06:35 PM, Thomas Monjalon wrote: > There was a prior call with an explanation of what needs to be done: > http://dpdk.org/ml/archives/dev/2016-June/040844.html > - Qemu patch upstreamed > - IVSHMEM PCI device managed by a PCI driver > - No DPDK objects (ring/mempool) allocated by EAL > > As nobody seems interested, it is time to remove this code which > makes EAL improvements harder. > > Signed-off-by: Thomas Monjalon > Acked-by: David Marchand > > --- > doc/guides/rel_notes/deprecation.rst | 3 +++ > 1 file changed, 3 insertions(+) Acked-by: Maxime Coquelin Thanks! Maxime
[dpdk-dev] [PATCH v2] doc: announce ABI change for rte_eth_dev structure
> -Original Message- > From: Jerin Jacob [mailto:jerin.jacob at caviumnetworks.com] > Sent: Wednesday, July 27, 2016 6:11 PM > To: Thomas Monjalon > Cc: Kulasek, TomaszX ; dev at dpdk.org; > Ananyev, Konstantin > Subject: Re: [dpdk-dev] [PATCH v2] doc: announce ABI change for rte_eth_dev > structure > > On Wed, Jul 27, 2016 at 01:59:01AM -0700, Thomas Monjalon wrote: > > > > Signed-off-by: Tomasz Kulasek > > > > --- > > > > +* In 16.11 ABI changes are plained: the ``rte_eth_dev`` structure > > > > +will be > > > > + extended with new function pointer ``tx_pkt_prep`` allowing > > > > +verification > > > > + and processing of packet burst to meet HW specific requirements > > > > +before > > > > + transmit. Also new fields will be added to the ``rte_eth_desc_lim`` > > > > structure: > > > > + ``nb_seg_max`` and ``nb_mtu_seg_max`` provideing information > > > > +about number of > > > > + segments limit to be transmitted by device for TSO/non-TSO packets. > > > > > > Acked-by: Konstantin Ananyev > > > > I think I understand you want to split the TX processing: > > 1/ modify/write in mbufs > > 2/ write in HW > > and let application decide: > > - where the TX prep is done (which core) > > In what basics applications knows when and where to call tx_pkt_prep in fast > path. > if all the time it needs to call before tx_burst then the PMD won't > have/don't need this callback waste cycles in fast path.Is this the expected > behavior ? > Anything think it as compile time to make other PMDs wont suffer because of > this change. Not sure what suffering you are talking about... Current model - i.e. when application does preparations (or doesn't if none is required) on its own and just call tx_burst() would still be there. If the app doesn't want to use tx_prep() by some reason - that still ok, and decision is up to the particular app. Konstantin > > > > - what to do if the TX prep fail > > So adding some processing in this first part becomes "not too > > expensive" or "manageable" from the application point of view. > > > > If I well understand the intent, > > > > Acked-by: Thomas Monjalon (except typos ;)
[dpdk-dev] [ovs-discuss] OVS DPDK|DPDK|ERR|interface dpdk0 start error:operation not permitted.
> On Jul 27, 2016, at 12:25 AM, sothy shan wrote: > > On Tue, Jul 26, 2016 at 6:32 PM, Mauricio Vasquez > wrote: >> Hello Sothy, >> >> Sorry for the delay in answering, some busy days here. >> >> >> On 07/25/2016 12:03 PM, sothy shan wrote: >>> >>> Hello Mauricio, >>> >>> On Sun, Jul 24, 2016 at 12:17 PM, Mauricio Vasquez >>> wrote: Hi Sothy, On 07/21/2016 11:55 AM, sothy shan wrote: > > On Thu, Jul 21, 2016 at 11:43 AM, Mauricio Vasquez > wrote: >> >> >> On 07/21/2016 10:51 AM, sothy shan wrote: >>> >>> On Thu, Jul 21, 2016 at 10:41 AM, sothy shan >>> wrote: On Wed, Jul 20, 2016 at 9:02 PM, Mauricio Vasquez wrote: > > Hi Sothy, > > On 07/20/2016 07:40 PM, Aaron Conole wrote: >> >> sothy shan writes: >> >>> Hello all, >> >> Hi Sothy, >> >>> I followed the installion guide provided in the web site >>> >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openvswitch_ovs_blob_master_INSTALL.DPDK.md-23ovstc=CwIBaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=44mSO5N5yEs4CeCdtQE0xt0F7J0p67_mApYVAzyYms0=vpaHcL64W3vOTY9P8yRZOdCJzbL_oWzZH6J2u4iT614=ojiXK7Tj1ANsHE_AlchVROP4R7LrgLQqVqTx7BjJQas= >>> >>> to install dpdk OVS. >>> >>> I am rurnning Ubuntu 14.04 (kernel 3.13). It is a VM running >>> VMware. >>> One intereface is enabled by VMXNET3. > > > It is not clear for me, are you trying to install OvS within the VM? > >>> I used dpdk 16.04 >>> Today I made clone of OVS (committ >>> :bf32e3e2c029da18b5d6fd9210cb0ea12a1d0383). >>> >>> The following are different configuration compared to above link. >>> >>> sysctl -w vm.nr_hugepages=2048 >>> Binded interface via igb_uio. >>> >>> Then followed same configuration to start ovs-vsswitch with dpdk. >> >> Can you please post the steps exactly that you followed? Which >> user >> you >> were running as, etc? Can you also post how you expect packets to >> arrive into the vm? >> >>> I am able to creatre bridge. When I create a port. It gives error >>> message. >> >> Please show the steps for this, too. The exact commands you used. >> >>> When I check ovs-vswitchd.log file, >>> >>> There is warning that dpif_netlink|WARN|genric netlink family, >>> ovs_datapath does not exist. The openvswitch kernel module may be >>> not >>> loaded. >> >> This is definitely a problem. How did you start the ovs-vswitchd >> daemon? > > > This is not a problem Aaron, the ovs kernel module is not needed > when > ovs is > compiled with DPDK. >>> >>> Then ERR: ERR|interface dpdk0 start error:operation not permitted. >>> >>> The corresponding port is loaded by dpdk driver as shown in >>> dpdk_nic_bind --status. >>> >>> After that I did sudo ovs-vsctl show. it show br and port details >>> as >>> well. >>> I am able to add one flow rule as well. But ovs bridge didnt get >>> packets from the interface. >>> >>> Do you know why this error is popup? anyway to solve the problem? >>> >>> Thank you very much >>> >>> Best regars >>> Sothy >> >> ___ >> discuss mailing list >> discuss at openvswitch.org >> https://urldefense.proofpoint.com/v2/url?u=http-3A__openvswitch.org_mailman_listinfo_discuss=CwIBaQ=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=44mSO5N5yEs4CeCdtQE0xt0F7J0p67_mApYVAzyYms0=vpaHcL64W3vOTY9P8yRZOdCJzbL_oWzZH6J2u4iT614=DZpyuDSP-5BYH4bvfNHk68XRFB9-M-M43FxZCCpZKho= >> > > As Aaron wrote, having the exact commands is important to help you. My configuration and log info: sudo sysctl vm.nr_hugepages=2048 sudo mkdir -p /dev/hugepages sudo mount -t hugetlbfs hugetlbfs /dev/hugepages sudo modprobe uio sudo insmod $DPDK_BUILD/kmod/igb_uio.ko sudo $DPDK_DIR/tools/dpdk_nic_bind.py --status sudo $DPDK_DIR/tools/dpdk_nic_bind.py -b igb_uio :0b:00.0 sudo ./dpdk-16.04/tools/dpdk_nic_bind.py --status Network devices using DPDK-compatible driver :0b:00.0 'VMXNET3 Ethernet Controller' drv=igb_uio unused= :13:00.0 'VMXNET3 Ethernet Controller' drv=igb_uio unused= Network devices using kernel driver
[dpdk-dev] usages issue with external mempool
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Wednesday, July 27, 2016 7:05 PM > To: Hemant Agrawal > Cc: Jerin Jacob ; David Hunt > ; dev at dpdk.org; olivier.matz at 6wind.com; > viktorin at rehivetech.com; Shreyansh Jain > Subject: Re: usages issue with external mempool > > 2016-07-27 13:23, Hemant Agrawal: > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > 2016-07-27 15:21, Jerin Jacob: > > > > If we agree on this then may be I can send the API deprecation > > > > notices for rte_mempool_create for v16.11 > > > > > > It would have been a lot better to send a patch during the 16.07 > > > cycle to avoid breaking again the API. > > > I'm afraid it will even be too late for the deprecation notice. > > > > [Hemant] Yes! It is late. > > we can make these changes immediately after 16.07. > > You cannot change the API in 16.11 without having a deprecation agreement in > 16.07. [Hemant] Can you still accommodate the deprecation notice for 16.07?
[dpdk-dev] [bug] dpdk-vfio: Invalid region/index assumption
Hi, I took a quick look at the dpdk vfio code and spotted an invalid assumption that should probably be corrected ASAP. That is: lib/librte_eal/linuxapp/eal/eal_vfio.h: #define VFIO_GET_REGION_ADDR(x) ((uint64_t) x << 40ULL) #define VFIO_GET_REGION_IDX(x) (x >> 40) Region offset to index is an implementation detail of the kernel, the vfio API defines that the offset of a given region (BAR) is found via the offset field of struct vfio_region_info returned via the VFIO_DEVICE_GET_REGION_INFO ioctl. You're free to cache the offset into any sort of local variable you like, but the kernel may change the implementation of region index to offset at any point in time. This is explicitly not part of the ABI. Is there a place to file a bug, or is this sufficient? Thanks, Alex
[dpdk-dev] [PATCH] net/e1000: fix return value of eth_igb_rx_queue_count()
Signed-off-by: Ali Volkan ATLI --- drivers/net/e1000/igb_rxtx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/e1000/igb_rxtx.c b/drivers/net/e1000/igb_rxtx.c index 9d80a0b..c5db727 100644 --- a/drivers/net/e1000/igb_rxtx.c +++ b/drivers/net/e1000/igb_rxtx.c @@ -1528,7 +1528,7 @@ eth_igb_rx_queue_count(struct rte_eth_dev *dev, uint16_t rx_queue_id) desc - rxq->nb_rx_desc]); } - return 0; + return desc; } int -- 1.8.3.1
[dpdk-dev] usages issue with external mempool
2016-07-27 13:23, Hemant Agrawal: > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > 2016-07-27 15:21, Jerin Jacob: > > > If we agree on this then may be I can send the API deprecation notices > > > for rte_mempool_create for v16.11 > > > > It would have been a lot better to send a patch during the 16.07 cycle to > > avoid > > breaking again the API. > > I'm afraid it will even be too late for the deprecation notice. > > [Hemant] Yes! It is late. > we can make these changes immediately after 16.07. You cannot change the API in 16.11 without having a deprecation agreement in 16.07.
[dpdk-dev] usages issue with external mempool
On Tue, Jul 26, 2016 at 10:11:13AM +, Hemant Agrawal wrote:
> Hi,
>There was lengthy discussions w.r.t external mempool patches.
> However, I am still finding usages issue with the agreed approach.
>
> The existing API to create packet mempool, "rte_pktmbuf_pool_create" does not
> provide the option to change the object init iterator. This may be the reason
> that many applications (e.g. OVS) are using rte_mempool_create to create
> packet mempool with their own object iterator (e.g. ovs_rte_pktmbuf_init).
>
> e.g the existing usages are:
> dmp->mp = rte_mempool_create(mp_name, mp_size, MBUF_SIZE(mtu),
> MP_CACHE_SZ,
> sizeof(struct rte_pktmbuf_pool_private),
> rte_pktmbuf_pool_init, NULL,
> ovs_rte_pktmbuf_init, NULL,
> socket_id, 0);
>
>
> With the new API set for packet pool create, this need to be changed to:
>
> dmp->mp = rte_mempool_create_empty(mp_name, mp_size, MBUF_SIZE(mtu),
> MP_CACHE_SZ,
> sizeof(struct rte_pktmbuf_pool_private),
> socket_id, 0);
> if (dmp->mp == NULL)
> break;
>
> rte_errno = rte_mempool_set_ops_byname(dmp-mp,
>
> RTE_MBUF_DEFAULT_MEMPOOL_OPS, NULL);
> if (rte_errno != 0) {
> RTE_LOG(ERR, MBUF, "error
> setting mempool handler\n");
> return NULL;
> }
> rte_pktmbuf_pool_init(dmp->mp, NULL);
>
> ret = rte_mempool_populate_default(dmp->mp);
> if (ret < 0) {
> rte_mempool_free(dmp->mp);
> rte_errno = -ret;
> return NULL;
> }
>
> rte_mempool_obj_iter(dmp->mp,
> ovs_rte_pktmbuf_init, NULL);
>
> This is not a user friendly approach to ask for changing 1 API to 6 new APIs.
> Or, am I missing something?
I agree, To me, this is very bad. I have raised this concern earlier
also
Since applications like OVS goes through "rte_mempool_create" for
even packet buffer pool creation. IMO it make senses to extend
"rte_mempool_create" to take one more argument to provide external pool
handler name(NULL for default). I don't see any valid technical reason
to treat external pool handler based mempool creation API different
from default handler.
Oliver, David
Thoughts ?
If we agree on this then may be I can send the API deprecation notices for
rte_mempool_create for v16.11
Jerin
>
> I think, we should do one of the following:
>
> 1. Enhance "rte_pktmbuf_pool_create" to optionally accept
> "rte_mempool_obj_cb_t *obj_init, void *obj_init_arg" as inputs. If obj_init
> is not present, default can be used.
> 2. Create a new wrapper API (e.g. e_pktmbuf_pool_create_new) with the above
> said behavior e.g.:
> /* helper to create a mbuf pool */
> struct rte_mempool *
> rte_pktmbuf_pool_create_new(const char *name, unsigned n,
>unsigned cache_size, uint16_t priv_size, uint16_t
> data_room_size,
> rte_mempool_obj_cb_t *obj_init, void *obj_init_arg,
>int socket_id)
> 3. Let the existing rte_mempool_create accept flag as
> "MEMPOOL_F_HW_PKT_POOL". Obviously, if this flag is set - all other flag
> values should be ignored. This was discussed earlier also.
>
> Please share your opinion.
>
> Regards,
> Hemant
>
>
[dpdk-dev] [PATCH v2] doc: improve wording of new features section
Improve the wording of some text in the "new features" section of the release notes. Signed-off-by: Bruce Richardson Signed-off-by: John McNamara --- doc/guides/rel_notes/release_16_07.rst | 28 1 file changed, 16 insertions(+), 12 deletions(-) diff --git a/doc/guides/rel_notes/release_16_07.rst b/doc/guides/rel_notes/release_16_07.rst index d00a6ed..a100e99 100644 --- a/doc/guides/rel_notes/release_16_07.rst +++ b/doc/guides/rel_notes/release_16_07.rst @@ -34,32 +34,36 @@ New Features Refer to the previous release notes for examples. -* **Removed mempool cache if not needed.** +* **Removed the mempool cache memory if caching is not being used.** The size of the mempool structure is reduced if the per-lcore cache is disabled. * **Added mempool external cache for non-EAL thread.** Added new functions to create, free or flush a user-owned mempool - cache for non-EAL threads. Previously the cache was always disabled + cache for non-EAL threads. Previously the caching was always disabled on these threads. -* **Changed the memory allocation in mempool library.** +* **Changed the memory allocation scheme in the mempool library.** - * Added ability to allocate a large mempool in virtually fragmented memory. + * Added the ability to allocate a large mempool in fragmented virtual memory. * Added new APIs to populate a mempool with memory. * Added an API to free a mempool. * Modified the API of the ``rte_mempool_obj_iter()`` function. - * Dropped specific Xen Dom0 code. - * Dropped specific anonymous mempool code in testpmd. + * Dropped the specific Xen Dom0 code. + * Dropped the specific anonymous mempool code in testpmd. -* **Added new driver for Broadcom NetXtreme-C devices.** +* **Added a new driver for Broadcom NetXtreme-C devices.** Added the new bnxt driver for Broadcom NetXtreme-C devices. See the "Network Interface Controller Drivers" document for more details on this new driver. -* **Added new driver for ThunderX nicvf device.** +* **Added a new driver for ThunderX nicvf devices.** + + Added the new thunderx net driver for ThunderX nicvf devices. See the + "Network Interface Controller Drivers" document for more details on this new + driver. * **Added mailbox interrupt support for ixgbe and igb VFs.** @@ -123,8 +127,8 @@ New Features DPDK vhost-user will also try to reconnect by default when: - * The first connect fails (when QEMU is not started yet). - * The connection is broken (when QEMU restarts). + * The first connect fails (for example when QEMU is not started yet). + * The connection is broken (for example when QEMU restarts). It can be turned off by setting the ``RTE_VHOST_USER_NO_RECONNECT`` flag. @@ -135,7 +139,7 @@ New Features Now AESNI MB PMD supports 128/192/256-bit counter mode AES encryption and decryption. -* **Added support for AES counter mode with Intel QuickAssist devices.** +* **Added AES counter mode support for Intel QuickAssist devices.** Enabled support for the AES CTR algorithm for Intel QuickAssist devices. Provided support for algorithm-chaining operations. @@ -168,7 +172,7 @@ New Features * **Added keepalive enhancements.** - Added support for reporting of core states other than dead to + Added support for reporting of core states other than "dead" to monitoring applications, enabling the support of broader liveness reporting to external processes. -- 2.7.4
[dpdk-dev] usages issue with external mempool
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > 2016-07-27 15:21, Jerin Jacob: > > On Tue, Jul 26, 2016 at 10:11:13AM +, Hemant Agrawal wrote: > > > This is not a user friendly approach to ask for changing 1 API to 6 new > > > APIs. > Or, am I missing something? > > > > I agree, To me, this is very bad. I have raised this concern earlier > > also > > > > Since applications like OVS goes through "rte_mempool_create" for even > > packet buffer pool creation. IMO it make senses to extend > > "rte_mempool_create" to take one more argument to provide external > > pool handler name(NULL for default). I don't see any valid technical > > reason to treat external pool handler based mempool creation API > > different from default handler. [Hemant] It is better. However, I will also suggest to upgrade "rte_pktmbuf_pool_create" with obj_init, this will create consistency in applications to use it instead of using rte_mempool_create. > > > > Oliver, David > > > > Thoughts ? > > > > If we agree on this then may be I can send the API deprecation notices > > for rte_mempool_create for v16.11 > > It would have been a lot better to send a patch during the 16.07 cycle to > avoid > breaking again the API. > I'm afraid it will even be too late for the deprecation notice. [Hemant] Yes! It is late. we can make these changes immediately after 16.07.
[dpdk-dev] segmentation fault: malloc_elem_alloc()-> LIST_REMOVE() [FreeBSD 10.3, dpdk-16.04)
Hello all,
While running as a secondary process I received the segmentation fault as
below on FreeBSD 10.3 and dpdk 16.04:
Program received signal SIGSEGV, Segmentation fault -
[Switching to Thread 801c06400 (LWP 100363/test_client)]
0x00416dcf in malloc_elem_alloc (elem=0x838e57000, size=64,
align=, bound=)
at dpdk-16.04/lib/librte_eal/common/malloc_elem.c:196
196 LIST_REMOVE(elem, free_list);
Current language: auto; currently minimal
(gdb) bt
#0 0x00416dcf in malloc_elem_alloc (elem=0x838e57000, size=64,
align=,
bound=) at
dpdk-16.04/lib/librte_eal/common/malloc_elem.c:196
#1 0x004174a7 in malloc_heap_alloc (heap=0x800698a1c, type=, size=64,
flags=, align=, bound=0)
at dpdk-16.04/lib/librte_eal/common/malloc_heap.c:168
#2 0x00416416 in rte_malloc_socket (type=0x41fdf8
"RING_TAILQ_ENTRY", size=24, align=,
socket_arg=Error accessing memory address 0x: Bad
address.
) at dpdk-16.04/lib/librte_eal/common/rte_malloc.c:91
#3 0x004164d4 in rte_zmalloc (type=0x838e57000 "\034jj", size=24,
align=0)
at dpdk-16.04/lib/librte_eal/common/rte_malloc.c:126
#4 0x00419044 in rte_ring_create (name=0x7fffe7e0
"spdk_active_pollers_6", count=4096, socket_id=0, flags=3)
at dpdk-16.04/lib/librte_ring/rte_ring.c:177
Segmentation fault happened in line 518 below (sys/queue.h)
510 #define LIST_REMOVE(elm, field) do {
\
511 QMD_SAVELINK(oldnext, (elm)->field.le_next);
\
512 QMD_SAVELINK(oldprev, (elm)->field.le_prev);
\
513 QMD_LIST_CHECK_NEXT(elm, field);
\
514 QMD_LIST_CHECK_PREV(elm, field);
\
515 if (LIST_NEXT((elm), field) != NULL)
\
516 LIST_NEXT((elm), field)->field.le_prev =
\
517 (elm)->field.le_prev;
\
518 *(elm)->field.le_prev = LIST_NEXT((elm), field);
\
519 TRASHIT(*oldnext);
\
520 TRASHIT(*oldprev);
\
521 } while (0)
522
It seems like the le_prev is not a valid address when being accessed from
the secondary process however the same address is valid when accessed from
the primary process (see below). Any idea what is going on here ?
Secondary process :
(gdb) p rte_config
$1 = {master_lcore = 7, lcore_count = 2, lcore_role = {ROLE_OFF, ROLE_OFF,
ROLE_OFF, ROLE_OFF, ROLE_OFF, ROLE_OFF, ROLE_RTE,
ROLE_RTE, ROLE_OFF }, process_type =
RTE_PROC_SECONDARY, mem_config = 0x800666000}
(gdb) p (struct rte_mem_config)*0x800666000
$2 = {magic = 19820526, nchannel = 4, nrank = 0, mlock = {cnt = 0}, qlock =
{cnt = 0}, mplock = {cnt = 0}, memzone_cnt = 22,
memseg = {{phys_addr = 6442450944, {addr = 0x80200, addr_64 =
34393292800}, len = 1073741824,
hugepage_sz = 1073741824, socket_id = 0, nchannel = 0, nrank = 0},
{phys_addr = 0, {addr = 0x0, addr_64 = 0}, len = 0,
hugepage_sz = 0, socket_id = 0, nchannel = 0, nrank = 0} }, memzone = {{
.
malloc_heaps = {{lock = {locked = 1},
free_head = {{lh_first = 0x0}, {lh_first = 0x0}, {lh_first =
0x838e57000}, {lh_first = 0x0}, {lh_first = 0x0}, {
lh_first = 0x0}, {lh_first = 0x0}, {lh_first = 0x0}, {lh_first =
0x0}, {lh_first = 0x0}, {lh_first = 0x0},
..
(gdb) p (struct malloc_elem)*0x838e57000
$3 = {heap = 0x8006a6a1c, prev = 0x838dd6fc0, free_list = {le_next =
0x838e59000, le_prev = 0x8006a6a34}, ms = 0x80067401c,
state = ELEM_FREE, pad = 0, size = 4032}
(gdb) p (struct malloc_elem)*0x838e59000
$4 = {heap = 0x8006a6a1c, prev = 0x838e57fc0, free_list = {le_next =
0x838e5e000, le_prev = 0x8006a6a34}, ms = 0x80067401c,
state = ELEM_FREE, pad = 0, size = 4032}
*(gdb) p (struct malloc_elem)*0x8006a6a34*
*Error accessing memory address 0x8006a6a34: Bad address.*
Primary process:
(gdb) p rte_config
$1 = {master_lcore = 0, lcore_count = 6, lcore_role = {ROLE_RTE, ROLE_RTE,
ROLE_RTE, ROLE_RTE, ROLE_RTE, ROLE_RTE,
ROLE_OFF }, process_type = RTE_PROC_PRIMARY,
mem_config = 0x800674000}
(gdb) p (struct rte_mem_config)*0x800674000
$2 = {magic = 19820526, nchannel = 4, nrank = 0, mlock = {cnt = 0}, qlock =
{cnt = 0}, mplock = {cnt = 0}, memzone_cnt = 22,
memseg = {{phys_addr = 6442450944, {addr = 0x80200, addr_64 =
34393292800}, len = 1073741824,
hugepage_sz = 1073741824, socket_id = 0, nchannel = 0, nrank = 0},
{phys_addr = 0, {addr = 0x0, addr_64 = 0}, len = 0,
malloc_heaps = {{lock = {locked = 1},
free_head = {{lh_first = 0x0}, {lh_first = 0x0}, {lh_first =
0x838e57000},
...
(gdb) p (struct malloc_elem)*0x838e57000
$3 = {heap = 0x8006a6a1c, prev = 0x838dd6fc0, free_list = {le_next =
0x838e59000, le_prev = 0x8006a6a34}, ms = 0x80067401c,
state = ELEM_FREE, pad = 0, size = 4032}
*(gdb) p (struct malloc_elem)*0x8006a6a34*
*$4 = {heap = 0x838e57000, prev = 0x0, free_list = {le_next = 0x0, le_prev
= 0x0}, ms = 0x0, state = ELEM_FREE, pad = 0,*
* size = 0}*
--Tyc
[dpdk-dev] Compiler hardening flags for libraries and performance implications
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Matthew Hall > Sent: Tuesday, July 26, 2016 5:44 PM > To: Luca Boccassi > Cc: dev at dpdk.org; christian.ehrhardt at canonical.com; > cjcollier at linuxfoundation.org; ricardo.salveti at linaro.org > Subject: Re: [dpdk-dev] Compiler hardening flags for libraries and > performance implications > > On Tue, Jul 26, 2016 at 02:53:13PM +, Luca Boccassi wrote: > > While working on uploading DPDK to Ubuntu and Debian, we were > > wondering if anyone had any thoughts/opinions on enabling compiler > > hardening flags for the DPDK libraries and the possible performance > implications. > > Most of the C profilers, both VTune and Perf based tools, have not given > me that much helpful data. They make it very hard to go from slow > functions down to actual slow lines of code causing performance issues > that I should fix. So I would love to see a MUCH better DPDK tuning guide, > because the current one is really generic and gives no useful advice > beyond what any programmer has already heard many times that doesn't > really add much value. Hi Matthew, Maybe you kick this off and submit something to the new howto section of the docs with whatever tuning tips you have so far. Then we can get people to contribute over time until we have something more useful. John
[dpdk-dev] [PATCH v2] doc: announce ABI change of struct rte_port_source_params and rte_port_sink_params
2016-07-27 10:08, Dumitrescu, Cristian: > As Thomas mentioned, today is probably the last day to discuss ABI changes. > This one is pretty small and straightforward, any issues with it? > > Panu had a concern that the change from "char *" to "const char *" is too > small to be regarded as ABI breakage and we should simply go ahead and do it. > My conservative proposal was to put a notice anyway. > > Nonetheless, what I would like to get from Thomas and Panu is a path forward > for this now: > a) If we agree to consider this an ABI change, please merge the notice for > 16.7; Panu was noticing 3 things (and I agree with them): - it is an API change - they can be grouped in only one list item - it is better to wait having more changes to break an API About the third point, in this specific case, I think it is acceptable because: - it should not break the ABI - the impact of the API change is really small - I'm not sure the packet framework should be considered as a DPDK API. > b) If we agree this is too small for an ABI change, please let us agree now > to accept our quick patch for 16.11 for this change. For an API deprecation notice (reworded), Acked-by: Thomas Monjalon > > -Original Message- > > The ABI changes are planned for rte_port_source_params and > > rte_port_sink_params, which will be supported from release 16.11. Here > > announces that ABI changes in detail. > > > > Signed-off-by: Fan Zhang > > Acked-by: Cristian Dumitrescu > > --- > > +* ABI will change for rte_port_source_params struct. The member > > file_name > > + data type will be changed from char * to const char *. This change > > targets > > + release 16.11 > > + > > +* ABI will change for rte_port_sink_params struct. The member file_name > > + data type will be changed from char * to const char *. This change > > targets > > + release 16.11
[dpdk-dev] [PATCH v2] doc: update guide and release notes for mlx5
Signed-off-by: Olga Shern --- doc/guides/nics/mlx5.rst |7 ++- doc/guides/rel_notes/release_16_07.rst | 14 ++ 2 files changed, 20 insertions(+), 1 deletions(-) diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst index 063c4a5..5c10cd3 100644 --- a/doc/guides/nics/mlx5.rst +++ b/doc/guides/nics/mlx5.rst @@ -154,6 +154,11 @@ Run-time configuration allows to save PCI bandwidth and improve performance at the cost of a slightly higher CPU usage. Enabled by default. + Supported on: + + - x86_64 with ConnectX4 and ConnectX4 LX + - Power8 with ConnectX4 LX + - ``txq_inline`` parameter [int] Amount of data to be inlined during TX operations. Improves latency. @@ -234,7 +239,7 @@ DPDK and must be installed separately: Currently supported by DPDK: -- Mellanox OFED **3.3-1.0.0.0**. +- Mellanox OFED **3.3-1.0.0.0** and **3.3-2.0.0.0**. - Minimum firmware version: diff --git a/doc/guides/rel_notes/release_16_07.rst b/doc/guides/rel_notes/release_16_07.rst index d00a6ed..4b43f8d 100644 --- a/doc/guides/rel_notes/release_16_07.rst +++ b/doc/guides/rel_notes/release_16_07.rst @@ -191,6 +191,20 @@ New Features Live migration of a VM with Virtio and VF PMD's using the bonding PMD. +* **Updated the mlx5 driver.** + + The mlx5 driver was updated with changes including the following: + + * Data path was refactored to bypass Verbs to improve RX and TX performance. + * Removed compilation parameters for inline send, ``MLX5_MAX_INLINE``, and +added command line parameter instead, ``txq_inline``. + * Improved TX scatter gather support: +Removed compilation parameter ``MLX5_PMD_SGE_WR_N``. +Scatter-gather elements is set to the maximum value the NIC supports. +Removed linearization logic, this decreases the memory consumption of the PMD. + * Improved jumbo frames support, by dynamically setting RX scatter gather elements +according to the MTU and mbuf size, +no need for compilation parameter ``MLX5_PMD_SGE_WR_N`` Resolved Issues --- -- 1.7.8.2
[dpdk-dev] usages issue with external mempool
2016-07-27 15:21, Jerin Jacob: > On Tue, Jul 26, 2016 at 10:11:13AM +, Hemant Agrawal wrote: > > This is not a user friendly approach to ask for changing 1 API to 6 new > > APIs. Or, am I missing something? > > I agree, To me, this is very bad. I have raised this concern earlier > also > > Since applications like OVS goes through "rte_mempool_create" for > even packet buffer pool creation. IMO it make senses to extend > "rte_mempool_create" to take one more argument to provide external pool > handler name(NULL for default). I don't see any valid technical reason > to treat external pool handler based mempool creation API different > from default handler. > > Oliver, David > > Thoughts ? > > If we agree on this then may be I can send the API deprecation notices for > rte_mempool_create for v16.11 It would have been a lot better to send a patch during the 16.07 cycle to avoid breaking again the API. I'm afraid it will even be too late for the deprecation notice.
[dpdk-dev] [PATCH v2] doc: update guide and release notes for mlx5
On Wed, Jul 27, 2016 at 12:27:26PM +0300, Olga Shern wrote: > Signed-off-by: Olga Shern > --- > doc/guides/nics/mlx5.rst |7 ++- > doc/guides/rel_notes/release_16_07.rst | 14 ++ > 2 files changed, 20 insertions(+), 1 deletions(-) > > diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst > index 063c4a5..5c10cd3 100644 > --- a/doc/guides/nics/mlx5.rst > +++ b/doc/guides/nics/mlx5.rst > @@ -154,6 +154,11 @@ Run-time configuration >allows to save PCI bandwidth and improve performance at the cost of a >slightly higher CPU usage. Enabled by default. > > + Supported on: > + > + - x86_64 with ConnectX4 and ConnectX4 LX > + - Power8 with ConnectX4 LX > + > - ``txq_inline`` parameter [int] > >Amount of data to be inlined during TX operations. Improves latency. > @@ -234,7 +239,7 @@ DPDK and must be installed separately: > > Currently supported by DPDK: > > -- Mellanox OFED **3.3-1.0.0.0**. > +- Mellanox OFED **3.3-1.0.0.0** and **3.3-2.0.0.0**. > > - Minimum firmware version: > > diff --git a/doc/guides/rel_notes/release_16_07.rst > b/doc/guides/rel_notes/release_16_07.rst > index d00a6ed..4b43f8d 100644 > --- a/doc/guides/rel_notes/release_16_07.rst > +++ b/doc/guides/rel_notes/release_16_07.rst > @@ -191,6 +191,20 @@ New Features > >Live migration of a VM with Virtio and VF PMD's using the bonding PMD. > > +* **Updated the mlx5 driver.** > + > + The mlx5 driver was updated with changes including the following: > + > + * Data path was refactored to bypass Verbs to improve RX and TX > performance. > + * Removed compilation parameters for inline send, ``MLX5_MAX_INLINE``, and > +added command line parameter instead, ``txq_inline``. > + * Improved TX scatter gather support: > +Removed compilation parameter ``MLX5_PMD_SGE_WR_N``. > +Scatter-gather elements is set to the maximum value the NIC supports. > +Removed linearization logic, this decreases the memory consumption of > the PMD. > + * Improved jumbo frames support, by dynamically setting RX scatter gather > elements > +according to the MTU and mbuf size, > +no need for compilation parameter ``MLX5_PMD_SGE_WR_N`` > > Resolved Issues > --- > -- > 1.7.8.2 Acked-by: Nelio Laranjeiro -- N?lio Laranjeiro 6WIND
[dpdk-dev] ACL: BUG: rte_acl_classify_scalar mismatch when use a special rule
Hi,
>
> define a rule as following:
>
> struct acl_ipv4_rule acl_rule[] = {
> {
> .data = {.userdata = 103, .category_mask = 1, .priority = 1},
> /* proto */
> .field[0] = {.value.u8 = 0, .mask_range.u8 = 0x0,},
> /* source IPv4 */
> .field[1] = {.value.u32 = IPv4(0, 0, 0, 0), .mask_range.u32 = 0,},
> /* destination IPv4 */
> .field[2] = {.value.u32 = IPv4(192, 168, 2, 4), .mask_range.u32 =
> 32,},
> /* source port */
> .field[3] = {.value.u16 = 0, .mask_range.u16 = 0x,},
> /* destination port */
> .field[4] = {.value.u16 = 1024, .mask_range.u16 = 0x,},
> },
> };
>
> build a pkt like this:
>
> pv4_hdr->next_proto_id = 6;
> ipv4_hdr->src_addr = rte_cpu_to_be_32(IPv4(10, 18, 2, 3));
> ipv4_hdr->dst_addr = rte_cpu_to_be_32(IPv4(192, 168, 2, 4));
> port = (uint16_t*)((unsigned char*)ipv4_hdr + sizeof(struct ipv4_hdr));
> port[0] = rte_cpu_to_be_16();
> port[1] = rte_cpu_to_be_16(4608);
>
> rte_acl_classify_scalar will mismatch this packet!
>
> i readed rte_acl_classify_scalar function, and found the reason:
>
> while (flows.started > 0) {
>
> input0 = GET_NEXT_4BYTES(parms, 0);
> input1 = GET_NEXT_4BYTES(parms, 1);
>
> for (n = 0; n < 4; n++) {
>
> transition0 = scalar_transition(flows.trans,
> transition0, (uint8_t)input0);
> input0 >>= CHAR_BIT;
>
> transition1 = scalar_transition(flows.trans,
> transition1, (uint8_t)input1);
> input1 >>= CHAR_BIT;
> }
>
> while ((transition0 | transition1) & RTE_ACL_NODE_MATCH) {
> transition0 = acl_match_check(transition0,
> 0, ctx, parms, , resolve_priority_scalar);
> transition1 = acl_match_check(transition1,
> 1, ctx, parms, , resolve_priority_scalar);
> }
> }
>
> everytime, scalar get 4bytes to transition, and usually it work well, but if
> we set a acl rule as prior, mismatch will appear.
> this is because field[3] is a 100% wild node, so it was removed as a
> deactivated field.
>
> in this situation, when rte_acl_classify_scalar runs, proto/sip/dip match ok,
> and then it skip sport because it was removed.
> now input0 is a int value(4 bytes) started form dport.
> it will get a match-node after 2 bytes match(dport is a short value), but
> cycle stoped untill n = 4, finally it translated to another node which is
> not a match-node, the mismatch happened.
>
> i'm not sure search_sse_8/search_sse_4/search_avx2x16 is Ok.
>
> how to fix it?
> i think set GET_NEXT_4BYTES to GET_NEXT_BYTE will solve this problem, but it
> will influence performance.
> another way, don't use acl_rule_stats to remove deactivated field, but code
> will change a lot.
If you believe there is a problem, could you try to reproduce it with
app/testacl,
and provide a rule file and a trace file?
Thanks
Konstantin
[dpdk-dev] last days for deprecation notices
Hi everybody, There are some announces pending to make some changes in 16.11 which will break the API or ABI: http://dpdk.org/dev/patchwork/project/dpdk/list/?q=announce Some of them are really good but will probably not happen because there is no visible consensus (or often no discussion at all). Such changes need 3 "meaningful" acks to be accepted: http://dpdk.org/browse/dpdk/tree/doc/guides/contributing/versioning.rst#n56 Note: 3 acks from the same company are not really "meaningful" ;) The release is planned on Thursday 28, so it is almost the last day to discuss these changes. Thanks
[dpdk-dev] [PATCH v4] doc: add section on tested platforms and nics and OSes
Add new section on tested platforms and nics and OSes to the release notes. Signed-off-by: Yulong Pei --- doc/guides/rel_notes/release_16_07.rst | 117 + 1 file changed, 117 insertions(+) diff --git a/doc/guides/rel_notes/release_16_07.rst b/doc/guides/rel_notes/release_16_07.rst index d00a6ed..64ba94d 100644 --- a/doc/guides/rel_notes/release_16_07.rst +++ b/doc/guides/rel_notes/release_16_07.rst @@ -400,6 +400,52 @@ Tested Platforms - Platform details. - Platform details. +#. SuperMicro 1U + + - BIOS: 1.0c + - Processor: Intel(R) Atom(TM) CPU C2758 @ 2.40GHz + +#. SuperMicro 1U + + - BIOS: 1.0a + - Processor: Intel(R) Xeon(R) CPU D-1540 @ 2.00GHz + - Onboard NIC: Intel(R) X552/X557-AT (2x10G) + + - Firmware-version: 0x81cf + - Device ID (PF/VF): 8086:15ad /8086:15a8 + + - kernel driver version: 4.2.5 (ixgbe) + +#. SuperMicro 2U + + - BIOS: 1.0a + - Processor: Intel(R) Xeon(R) CPU E5-4667 v3 @ 2.00GHz + +#. Intel(R) Server board S2600GZ + + - BIOS: SE5C600.86B.02.02.0002.122320131210 + - Processor: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz + +#. Intel(R) Server board W2600CR + + - BIOS: SE5C600.86B.02.01.0002.082220131453 + - Processor: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz + +#. Intel(R) Server board S2600CWT + + - BIOS: SE5C610.86B.01.01.0009.060120151350 + - Processor: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz + +#. Intel(R) Server board S2600WTT + + - BIOS: SE5C610.86B.01.01.0005.101720141054 + - Processor: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz + +#. Intel(R) Server board S2600WTT + + - BIOS: SE5C610.86B.11.01.0044.090120151156 + - Processor: Intel(R) Xeon(R) CPU E5-2695 v4 @ 2.10GHz + Tested NICs --- @@ -412,3 +458,74 @@ Tested NICs - NIC details. - NIC details. + +#. Intel(R) Ethernet Controller X540-AT2 + + - Firmware version: 0x8389 + - Device id (pf): 8086:1528 + - Driver version: 3.23.2 (ixgbe) + +#. Intel(R) 82599ES 10 Gigabit Ethernet Controller + + - Firmware version: 0x61bf0001 + - Device id (pf/vf): 8086:10fb / 8086:10ed + - Driver version: 4.0.1-k (ixgbe) + +#. Intel(R) Corporation Ethernet Connection X552/X557-AT 10GBASE-T + + - Firmware version: 0x81cf + - Device id (pf/vf): 8086:15ad / 8086:15a8 + - Driver version: 4.2.5 (ixgbe) + +#. Intel(R) Ethernet Converged Network Adapter X710-DA4 (4x10G) + + - Firmware version: 5.04 + - Device id (pf/vf): 8086:1572 / 8086:154c + - Driver version: 1.4.26 (i40e) + +#. Intel(R) Ethernet Converged Network Adapter X710-DA2 (2x10G) + + - Firmware version: 5.04 + - Device id (pf/vf): 8086:1572 / 8086:154c + - Driver version: 1.4.25 (i40e) + +#. Intel(R) Ethernet Converged Network Adapter XL710-QDA1 (1x40G) + + - Firmware version: 5.04 + - Device id (pf/vf): 8086:1584 / 8086:154c + - Driver version: 1.4.25 (i40e) + +#. Intel(R) Ethernet Converged Network Adapter XL710-QDA2 (2X40G) + + - Firmware version: 5.04 + - Device id (pf/vf): 8086:1583 / 8086:154c + - Driver version: 1.4.25 (i40e) + +#. Intel(R) Corporation I350 Gigabit Network Connection + + - Firmware version: 1.48, 0x86e7 + - Device id (pf/vf): 8086:1521 / 8086:1520 + - Driver version: 5.2.13-k (igb) + +#. Intel(R) Ethernet Multi-host Controller FM1 + + - Firmware version: N/A + - Device id (pf/vf): 8086:15d0 + - Driver version: 0.17.0.9 (fm10k) + + +Tested OSes +--- + +.. This section should contain a list of OSes that were tested with this release. + + - CentOS 7.0 + - Fedora 23 + - Fedora 24 + - FreeBSD 10.3 + - Red Hat Enterprise Linux 7.2 + - SUSE Enterprise Linux 12 + - Ubuntu 15.10 + - Ubuntu 16.04 LTS + - Wind River Linux 8 + -- 2.1.0
[dpdk-dev] [PATCH v2] doc: update guide and release notes for mlx5
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olga Shern > Sent: Wednesday, July 27, 2016 10:27 AM > To: dev at dpdk.org > Cc: Olga Shern > Subject: [dpdk-dev] [PATCH v2] doc: update guide and release notes for > mlx5 > > Signed-off-by: Olga Shern Acked-by: John McNamara
[dpdk-dev] [PATCH] doc: announce ivshmem support removal
On Wed, Jul 20, 2016 at 6:35 PM, Thomas Monjalon wrote: > There was a prior call with an explanation of what needs to be done: > http://dpdk.org/ml/archives/dev/2016-June/040844.html > - Qemu patch upstreamed > - IVSHMEM PCI device managed by a PCI driver > - No DPDK objects (ring/mempool) allocated by EAL > > As nobody seems interested, it is time to remove this code which > makes EAL improvements harder. > > Signed-off-by: Thomas Monjalon Acked-by: David Marchand -- David Marchand
[dpdk-dev] [PATCH v2] doc: announce ABI change for mbuf structure
> For 16.11, the mbuf structure will be modified implying ABI breakage. > Some discussions already took place here: > http://www.dpdk.org/dev/patchwork/patch/12878/ > > Signed-off-by: Olivier Matz Acked-by: Thomas Monjalon
[dpdk-dev] [PATCH] doc: deprecate vhost-cuse
> > Vhost-cuse was invented before vhost-user exist. The both are actually > > doing the same thing: a vhost-net implementation in user space. But they > > are not exactly the same thing. > > > > Firstly, vhost-cuse is harder for use; no one seems to care it, either. > > Furthermore, since v2.1, a large majority of development effort has gone > > to vhost-user. For example, we extended the vhost-user spec to add the > > multiple queue support. We also added the vhost-user live migration at > > v16.04 and the latest one, vhost-user reconnect that allows vhost app > > restart without restarting the guest. Both of them are very important > > features for product usage and none of them works for vhost-cuse. > > > > You now see that the difference between vhost-user and vhost-cuse is > > big (and will be bigger and bigger as time moves forward), that you > > should never use vhost-cuse, that we should drop it completely. > > > > The remove would also result to a much cleaner code base, allowing us > > to do all kinds of extending easier. > > > > So here to mark vhost-cuse as deprecated in this release and will be > > removed in the next release (v16.11). > > > > Signed-off-by: Yuanhan Liu > > Acked-by: Ciara Loftus Acked-by: Thomas Monjalon
[dpdk-dev] [PATCH] doc: announce driver name changes
2016-07-22 17:13, Adrien Mazarguil: > > > >> From: De Lara Guarch, Pablo > > > >>> Driver names for all the supported devices in DPDK do not have > > > >>> a naming convention. Some are using a prefix, some are not > > > >>> and some have long names. Driver names are used when creating > > > >>> virtual devices, so it is useful to have consistency in the names. > > > >>> > > > >>> Signed-off-by: Pablo de Lara > > So what about using "net/" instead of "net_" to share names with commit > prefixes and folders? +1 for net/ in names Anyway, Acked-by: Thomas Monjalon
[dpdk-dev] [PATCH v2] doc: announce ABI change of struct rte_port_source_params and rte_port_sink_params
As Thomas mentioned, today is probably the last day to discuss ABI changes. This one is pretty small and straightforward, any issues with it? Panu had a concern that the change from "char *" to "const char *" is too small to be regarded as ABI breakage and we should simply go ahead and do it. My conservative proposal was to put a notice anyway. Nonetheless, what I would like to get from Thomas and Panu is a path forward for this now: a) If we agree to consider this an ABI change, please merge the notice for 16.7; b) If we agree this is too small for an ABI change, please let us agree now to accept our quick patch for 16.11 for this change. Thanks, Cristian > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Fan Zhang > Sent: Thursday, May 19, 2016 3:19 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v2] doc: announce ABI change of struct > rte_port_source_params and rte_port_sink_params > > The ABI changes are planned for rte_port_source_params and > rte_port_sink_params, which will be supported from release 16.11. Here > announces that ABI changes in detail. > > Signed-off-by: Fan Zhang > Acked-by: Cristian Dumitrescu > --- > doc/guides/rel_notes/deprecation.rst | 8 > 1 file changed, 8 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index fffe9c7..4f3fefe 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -74,3 +74,11 @@ Deprecation Notices >a handle, like the way kernel exposes an fd to user for locating a >specific file, and to keep all major structures internally, so that >we are likely to be free from ABI violations in future. > + > +* ABI will change for rte_port_source_params struct. The member > file_name > + data type will be changed from char * to const char *. This change targets > + release 16.11 > + > +* ABI will change for rte_port_sink_params struct. The member file_name > + data type will be changed from char * to const char *. This change targets > + release 16.11 > -- > 2.5.5
[dpdk-dev] [PATCH] eal: fix parsing of argument of option --lcores
Hi Bynes
Thanks for your feedback.
> -Original Message-
> From: bynes adam [mailto:adambynes at outlook.com]
> Sent: Friday, July 22, 2016 4:45 AM
> To: Dai, Wei
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] eal: fix parsing of argument of option
> --lcores
>
> On Thu, Jul 21, 2016 at 02:03:38PM +0800, Wei Dai wrote:
> Hi Wei,
> > The '-' in lcores set overrides cpu set of following lcore set in the
> > argument of EAL option --lcores.
> >
> > Fixes: 53e54bf81700 ("eal: new option --lcores for cpu assignment")
> >
> > Signed-off-by: Wei Dai
> > ---
> > lib/librte_eal/common/eal_common_options.c | 12
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/lib/librte_eal/common/eal_common_options.c
> > b/lib/librte_eal/common/eal_common_options.c
> > index 0a594d7..96eb1a9 100644
> > --- a/lib/librte_eal/common/eal_common_options.c
> > +++ b/lib/librte_eal/common/eal_common_options.c
> > @@ -563,6 +563,7 @@ convert_to_cpuset(rte_cpuset_t *cpusetp,
> > * lcores, cpus could be a single digit/range or a group.
> > * '(' and ')' are necessary if it's a group.
> > * If not supply '@cpus', the value of cpus uses the same as lcores.
> > + * The 'a-b' in lcores not within '(' and ')' means a,a+1,...,b-1,b .
> this description is not very clear, a-b and (a-b) are both the same meaning.
> may be need a table for comparison
> a-b@(c-d)
> a-b at c-d
> (a-b)@c-d
> (a-b)@(c-d)
> all the above I believe are the same
> only the following two cases:
> a-b,
> (a-b),
With --lcores '0-3 at 12-15', eal_parse_cores( ) will fail because
eal_parse_set( )
find the next char after lcore set is '@' and is not ',' or '\0'.
So the bug in eal_parse_set( ) should be fixed.
A patch v3 will be provided.
After fixing, I test it with --lcores '0-3 at 12-15, 4-7@(8-11), (8-11)@4-7,
(12-15)@(0-3), 16-19, (20-23) '
It works well.
Thanks
Wei
> so the key point here is the @ and (), not only @
> > * e.g. '1,2@(5-7),(3-5)@(0,2),(0,6),7-8' means start 9 EAL thread as below
> > * lcore 0 runs on cpuset 0x41 (cpu 0,6)
> > * lcore 1 runs on cpuset 0x2 (cpu 1)
> > @@ -571,6 +572,15 @@ convert_to_cpuset(rte_cpuset_t *cpusetp,
> > * lcore 6 runs on cpuset 0x41 (cpu 0,6)
> > * lcore 7 runs on cpuset 0x80 (cpu 7)
> > * lcore 8 runs on cpuset 0x100 (cpu 8)
> > + * e.g. '0-2,(3-5)@(3,4),6@(5,6),7@(5-7)'means start 8 EAL threads as
> below
> > + * lcore 0 runs on cpuset 0x1 (cpu 0)
> > + * lcore 1 runs on cpuset 0x2 (cpu 1)
> > + * lcore 2 runs on cpuset ox4 (cpu 2)
> > + * lcore 3,4,5 runs on cpuset 0x18 (cpu 3,4)
> > + * lcore 6 runs on cpuset 0x60 (cpu 5,6)
> > + * lcore 7 runs on cpuset 0xe0 (cpu 5,6,7)
> > + * The second case is used to test bugfix for lflags not be cleared
> > + after use
> you can put this sentance and description into the commit log I don't think
> you
> should put bugfix description in comments here.
> > + */
> > */
> > static int
> > eal_parse_lcores(const char *lcores)
> > @@ -679,6 +689,8 @@ eal_parse_lcores(const char *lcores)
> >sizeof(rte_cpuset_t));
> > }
> >
> > + lflags = 0;
> > +
> > lcores = end + 1;
> > } while (*end != '\0');
> >
> > --
> > 2.5.5
> Adam Bynes
[dpdk-dev] [PATCH 09/12] virtio: add Rx checksum offload support
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier Matz
> Sent: Thursday, July 21, 2016 4:08 PM
> To: dev at dpdk.org; yuanhan.liu at linux.intel.com; Ananyev, Konstantin
>
> Cc: Chandran, Sugesh ; Richardson, Bruce
> ; Tan, Jianfeng ;
> Zhang,
> Helin ; adrien.mazarguil at 6wind.com
> Subject: [dpdk-dev] [PATCH 09/12] virtio: add Rx checksum offload support
>
> Signed-off-by: Olivier Matz
> ---
> drivers/net/virtio/virtio_ethdev.c | 14
> drivers/net/virtio/virtio_ethdev.h | 2 +-
> drivers/net/virtio/virtio_rxtx.c | 66
> ++
> drivers/net/virtio/virtqueue.h | 1 +
> 4 files changed, 75 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/virtio/virtio_ethdev.c
> b/drivers/net/virtio/virtio_ethdev.c
> index 02eae94..c0f1f21 100644
> --- a/drivers/net/virtio/virtio_ethdev.c
> +++ b/drivers/net/virtio/virtio_ethdev.c
> @@ -1262,7 +1262,7 @@ eth_virtio_dev_init(struct rte_eth_dev *eth_dev)
> eth_dev->data->dev_flags = dev_flags;
>
> /* reset device and negotiate default features */
> - ret = virtio_init_device(eth_dev, VIRTIO_PMD_GUEST_FEATURES);
> + ret = virtio_init_device(eth_dev,
> VIRTIO_PMD_DEFAULT_GUEST_FEATURES);
> if (ret < 0)
> return ret;
>
> @@ -1351,13 +1351,10 @@ virtio_dev_configure(struct rte_eth_dev *dev)
> int ret;
>
> PMD_INIT_LOG(DEBUG, "configure");
> + req_features = VIRTIO_PMD_DEFAULT_GUEST_FEATURES;
> + if (rxmode->hw_ip_checksum)
> + req_features |= (1ULL << VIRTIO_NET_F_GUEST_CSUM);
>
> diff --git a/drivers/net/virtio/virtio_rxtx.c
> b/drivers/net/virtio/virtio_rxtx.c
> index 9aba044..a18798f 100644
> --- a/drivers/net/virtio/virtio_rxtx.c
> +++ b/drivers/net/virtio/virtio_rxtx.c
> @@ -613,6 +613,54 @@ virtio_update_packet_stats(struct virtnet_stats *stats,
> struct rte_mbuf *mbuf)
> }
> }
>
> +/* Optionally fill offload information in structure */ static int
> +virtio_rx_offload(struct rte_mbuf *m, struct virtio_net_hdr *hdr) {
> + struct rte_mbuf_hdr_lens hdr_lens;
> + uint32_t hdrlen, ptype;
> + int l4_supported = 0;
> +
> + /* nothing to do */
> + if (hdr->flags == 0 && hdr->gso_type == VIRTIO_NET_HDR_GSO_NONE)
> + return 0;
> +
> + m->ol_flags |= PKT_RX_IP_CKSUM_UNKNOWN;
> +
> + ptype = rte_pktmbuf_get_ptype(m, _lens, RTE_PTYPE_ALL_MASK);
> + m->packet_type = ptype;
> + if ((ptype & RTE_PTYPE_L4_MASK) == RTE_PTYPE_L4_TCP ||
> + (ptype & RTE_PTYPE_L4_MASK) == RTE_PTYPE_L4_UDP ||
> + (ptype & RTE_PTYPE_L4_MASK) == RTE_PTYPE_L4_SCTP)
> + l4_supported = 1;
> +
> + if (hdr->flags & VIRTIO_NET_HDR_F_NEEDS_CSUM) {
> + hdrlen = hdr_lens.l2_len + hdr_lens.l3_len + hdr_lens.l4_len;
> + if (hdr->csum_start <= hdrlen && l4_supported) {
> + m->ol_flags |= PKT_RX_L4_CKSUM_NONE;
> + } else {
> + /* Unknown proto or tunnel, do sw cksum. We can
> assume
> + * the cksum field is in the first segment since the
> + * buffers we provided to the host are large enough.
> + * In case of SCTP, this will be wrong since it's a CRC
> + * but there's nothing we can do.
> + */
> + uint16_t csum, off;
> +
> + csum = ~rte_pktmbuf_cksum(m, hdr->csum_start,
> + rte_pktmbuf_pkt_len(m) - hdr->csum_start);
1. When translate raw_cksum to the final cksum, it should be like "(cksum ==
0x) ? cksum : ~cksum".
2. How about making this function inline as it's called in fast path?
Best Regards,
Xiao
[dpdk-dev] [PATCH] doc : update guide and release notes for mlx5
Thanks John Sent fixed patch including your comments Best Regards, Olga -Original Message- From: Mcnamara, John [mailto:john.mcnam...@intel.com] Sent: Wednesday, July 27, 2016 11:18 AM To: Olga Shern ; dev at dpdk.org Subject: RE: [dpdk-dev] [PATCH] doc : update guide and release notes for mlx5 > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olga Shern > Sent: Tuesday, July 26, 2016 5:29 PM > To: dev at dpdk.org > Cc: Olga Shern > Subject: [dpdk-dev] [PATCH] doc : update guide and release notes for > mlx5 > > ... > > +* **Updated the mlx5 driver.** > + > + The mlx5 driver was updated with changes including the following: > + > + * Data path was refactored to bypass Verbs to improve RX and TX > performance. > + * Removed compilation parameters for inline send, MLX5_MAX_INLINE, and > +added command line parameter instead, txq_inline. > + * Improved TX scatter gather support: > +Removed compilation parameter MLX5_PMD_SGE_WR_N. > +Scatter-gather elements is set to the maximum value the NIC supports. > +Removed linearization logic, this decreases the memory > + consumption of > the PMD. > + * Improved jumbo frames support, by dynamically setting RX scatter > gather elements > +according to the MTU and mbuf size, > +no need for compilation parameter MLX5_PMD_SGE_WR_N. > + Hi, There are 2 whitespace warnings in the patch. If you resubmit can you also put the MLX5 variables in fixed width quotes. Apart from that: Acked-by: John McNamara
[dpdk-dev] [PATCH v2] doc: announce ABI change for mbuf structure
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier Matz > Sent: Wednesday, July 20, 2016 8:16 AM > To: dev at dpdk.org > Cc: jerin.jacob at caviumnetworks.com; thomas.monjalon at 6wind.com; > Richardson, Bruce > Subject: [dpdk-dev] [PATCH v2] doc: announce ABI change for mbuf structure > > For 16.11, the mbuf structure will be modified implying ABI breakage. > Some discussions already took place here: > http://www.dpdk.org/dev/patchwork/patch/12878/ > > Signed-off-by: Olivier Matz > --- > > v1->v2: > - reword the sentences to keep things more open, as suggested by Bruce > > doc/guides/rel_notes/deprecation.rst | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > index f502f86..b9f5a93 100644 > --- a/doc/guides/rel_notes/deprecation.rst > +++ b/doc/guides/rel_notes/deprecation.rst > @@ -41,3 +41,9 @@ Deprecation Notices > * The mempool functions for single/multi producer/consumer are deprecated and >will be removed in 16.11. >It is replaced by rte_mempool_generic_get/put functions. > + > +* ABI changes are planned for 16.11 in the ``rte_mbuf`` structure: some > fields > + may be reordered to facilitate the writing of ``data_off``, ``refcnt``, and > + ``nb_segs`` in one operation, because some platforms have an overhead if > the > + store address is not naturally aligned. Other mbuf fields, such as the > + ``port`` field, may be moved or removed as part of this mbuf work. > -- Acked-by: Konstantin Ananyev > 2.8.1
[dpdk-dev] [ovs-discuss] OVS DPDK|DPDK|ERR|interface dpdk0 start error:operation not permitted.
On Tue, Jul 26, 2016 at 6:32 PM, Mauricio Vasquez wrote: > Hello Sothy, > > Sorry for the delay in answering, some busy days here. > > > On 07/25/2016 12:03 PM, sothy shan wrote: >> >> Hello Mauricio, >> >> On Sun, Jul 24, 2016 at 12:17 PM, Mauricio Vasquez >> wrote: >>> >>> Hi Sothy, >>> >>> >>> On 07/21/2016 11:55 AM, sothy shan wrote: On Thu, Jul 21, 2016 at 11:43 AM, Mauricio Vasquez wrote: > > > On 07/21/2016 10:51 AM, sothy shan wrote: >> >> On Thu, Jul 21, 2016 at 10:41 AM, sothy shan >> wrote: >>> >>> On Wed, Jul 20, 2016 at 9:02 PM, Mauricio Vasquez >>> wrote: Hi Sothy, On 07/20/2016 07:40 PM, Aaron Conole wrote: > > sothy shan writes: > >> Hello all, > > Hi Sothy, > >> I followed the installion guide provided in the web site >> >> https://github.com/openvswitch/ovs/blob/master/INSTALL.DPDK.md#ovstc >> to install dpdk OVS. >> >> I am rurnning Ubuntu 14.04 (kernel 3.13). It is a VM running >> VMware. >> One intereface is enabled by VMXNET3. It is not clear for me, are you trying to install OvS within the VM? >> I used dpdk 16.04 >> Today I made clone of OVS (committ >> :bf32e3e2c029da18b5d6fd9210cb0ea12a1d0383). >> >> The following are different configuration compared to above link. >> >> sysctl -w vm.nr_hugepages=2048 >> Binded interface via igb_uio. >> >> Then followed same configuration to start ovs-vsswitch with dpdk. > > Can you please post the steps exactly that you followed? Which > user > you > were running as, etc? Can you also post how you expect packets to > arrive into the vm? > >> I am able to creatre bridge. When I create a port. It gives error >> message. > > Please show the steps for this, too. The exact commands you used. > >> When I check ovs-vswitchd.log file, >> >> There is warning that dpif_netlink|WARN|genric netlink family, >> ovs_datapath does not exist. The openvswitch kernel module may be >> not >> loaded. > > This is definitely a problem. How did you start the ovs-vswitchd > daemon? This is not a problem Aaron, the ovs kernel module is not needed when ovs is compiled with DPDK. >> >> Then ERR: ERR|interface dpdk0 start error:operation not permitted. >> >> The corresponding port is loaded by dpdk driver as shown in >> dpdk_nic_bind --status. >> >> After that I did sudo ovs-vsctl show. it show br and port details >> as >> well. >> I am able to add one flow rule as well. But ovs bridge didnt get >> packets from the interface. >> >> Do you know why this error is popup? anyway to solve the problem? >> >> Thank you very much >> >> Best regars >> Sothy > > ___ > discuss mailing list > discuss at openvswitch.org > http://openvswitch.org/mailman/listinfo/discuss As Aaron wrote, having the exact commands is important to help you. >>> >>> My configuration and log info: >>> >>> sudo sysctl vm.nr_hugepages=2048 >>> sudo mkdir -p /dev/hugepages >>> sudo mount -t hugetlbfs hugetlbfs /dev/hugepages >>> sudo modprobe uio >>> sudo insmod $DPDK_BUILD/kmod/igb_uio.ko >>> sudo $DPDK_DIR/tools/dpdk_nic_bind.py --status >>> sudo $DPDK_DIR/tools/dpdk_nic_bind.py -b igb_uio :0b:00.0 >>> sudo ./dpdk-16.04/tools/dpdk_nic_bind.py --status >>> >>> >>> Network devices using DPDK-compatible driver >>> >>> :0b:00.0 'VMXNET3 Ethernet Controller' drv=igb_uio unused= >>> :13:00.0 'VMXNET3 Ethernet Controller' drv=igb_uio unused= >>> >>> Network devices using kernel driver >>> === >>> :03:00.0 'VMXNET3 Ethernet Controller' if=eth0 drv=vmxnet3 >>> unused=igb_uio *Active* >>> >>> Other network devices >>> = >>> >>> >>> .Then.. >>> >>> >>> sudo ovs-vsctl add-port br0 dpdk0 -- set Interface dpdk0 type=dpdk >>> sudo ovs-vsctl add-br br0 -- set bridge br0 datapath_type=netdev > > These two commands are inverted. > The bridge has to be created first and then ports have to be added to > it. > It is my mistake when coping. >>> >>> Log file/ >>> 2016-07-21T07:53:35.527Z|1|vlog|INFO|opened log file >>>
[dpdk-dev] [PATCH v2 1/2] eal: remove redundant codes to parse --lcores
Hi, Adam & Ananyev Thanks for your feedback. > -Original Message- > From: Adam Bynes [mailto:adambynes at outlook.com] > Sent: Wednesday, July 27, 2016 1:36 AM > To: Dai, Wei ; Ananyev, Konstantin > > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v2 1/2] eal: remove redundant codes to parse > --lcores > > On Tue, Jul 26, 2016 at 11:51:57AM +, Ananyev, Konstantin wrote: > > > > > hi Wei, > > > -Original Message- > > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wei Dai > > > Sent: Tuesday, July 26, 2016 10:52 AM > > > To: dev at dpdk.org > > > Cc: Dai, Wei > > > Subject: [dpdk-dev] [PATCH v2 1/2] eal: remove redundant codes to parse > --lcores > > > > > > local variable i is not referred by other codes in the function > eal_parse_lcores( ), so it can be removed. > > > > > > Signed-off-by: Wei Dai > > > --- > > > lib/librte_eal/common/eal_common_options.c | 4 > > > 1 file changed, 4 deletions(-) > > > > > > diff --git a/lib/librte_eal/common/eal_common_options.c > b/lib/librte_eal/common/eal_common_options.c > > > index 481c732..c5bf98c 100644 > > > --- a/lib/librte_eal/common/eal_common_options.c > > > +++ b/lib/librte_eal/common/eal_common_options.c > > > @@ -578,7 +578,6 @@ eal_parse_lcores(const char *lcores) > > > struct rte_config *cfg = rte_eal_get_configuration(); > > > static uint16_t set[RTE_MAX_LCORE]; > > > unsigned idx = 0; > > > - int i; > > > unsigned count = 0; > > > const char *lcore_start = NULL; > > > const char *end = NULL; > > > @@ -593,9 +592,6 @@ eal_parse_lcores(const char *lcores) > > > /* Remove all blank characters ahead and after */ > > > while (isblank(*lcores)) > > > lcores++; > > > - i = strlen(lcores); > > > - while ((i > 0) && isblank(lcores[i - 1])) > > > - i--; > > > > I suppose originally it meant to do something like that: > > while ((i > 0) && isblank(lcores[i - 1])) > > lcores[i--] = 0; > totally agreed Konstantin, need to add lcore[i--] = '\0' > > > > > to get rid of blank characters at the end of the line, no? > > Konstantin The tail blank is not necessary to be removed from lcores here for following reasons: 1. The tail blanks can also be swallowed later in function eal_parse_set( ) by "while (isblank(*end)) end++". And such operation/sentence also deal with blanks in the middle of arguments (for example: blank before - and after (7,8) in '0 -2,(3 - 6)@(3-6),7@(7-8) ,8@(8-10) '), so above removal of blank is redundant. By the way, with --lcores '(0-3)@(0-3), (4-5)@(4-5)', I also find a new bug. After processing cpu set (4-5), the variable end in eal_parse_lcores doesn't point t ',' or '\0', so this function return an error. The tail blank after cpu set (4-5) still need to be swallowed. The patch v3 will be removed.eal 2. if let lcores[i--] = 0 here, due to type of input argument lcores (const char *), building will fail. And if the type is changed to char *, the type of input argument of several other function also need to be changed. So according to above reason 1, it is not need to change the type. Thanks Wei Dai > > > > > > > > CPU_ZERO(); > > > > > > -- > > > 2.5.5 > Adam Bynes
[dpdk-dev] [PATCH] doc: deprecate vhost-cuse
On Wed, Jul 27, 2016 at 1:31 AM, Thomas Monjalon wrote: > > > Vhost-cuse was invented before vhost-user exist. The both are actually > > > doing the same thing: a vhost-net implementation in user space. But > they > > > are not exactly the same thing. > > > > > > Firstly, vhost-cuse is harder for use; no one seems to care it, either. > > > Furthermore, since v2.1, a large majority of development effort has > gone > > > to vhost-user. For example, we extended the vhost-user spec to add the > > > multiple queue support. We also added the vhost-user live migration at > > > v16.04 and the latest one, vhost-user reconnect that allows vhost app > > > restart without restarting the guest. Both of them are very important > > > features for product usage and none of them works for vhost-cuse. > > > > > > You now see that the difference between vhost-user and vhost-cuse is > > > big (and will be bigger and bigger as time moves forward), that you > > > should never use vhost-cuse, that we should drop it completely. > > > > > > The remove would also result to a much cleaner code base, allowing us > > > to do all kinds of extending easier. > > > > > > So here to mark vhost-cuse as deprecated in this release and will be > > > removed in the next release (v16.11). > > > > > > Signed-off-by: Yuanhan Liu > > > > Acked-by: Ciara Loftus > > Acked-by: Thomas Monjalon > Acked-by: Rich Lane
[dpdk-dev] Compiler hardening flags for libraries and performance implications
On Wed, Jul 27, 2016 at 12:58:12PM +, Mcnamara, John wrote: > Hi Matthew, > > Maybe you kick this off and submit something to the new howto section of the > docs with whatever tuning tips you have so far. > > Then we can get people to contribute over time until we have something more > useful. > > John Believe me, I'd really love to do so but I really don't have any clue about CFLAGS, how to find the problematic LOCs for CPU usage, cache misses, etc. I think I wrote some previous mails about different challenges I ran into. I feel like there is a certain amount of knowledge inside of Intel and 6WIND about these things that hasn't propagated to the rest of the community. Maybe we could find a way to have some hackathons in Silicon Valley where people could work on code or projects together? Then we could see about spreading and documenting some of the organic knowledge to improve the coding and tuning guides. The Meetups seem to demo new features but they don't talk about testing and tuning there sadly. I'm really up for any ideas, it's something I struggled with ever since the beginning of when I used DPDK 1.x in 2011. Matthew.
[dpdk-dev] [PATCH] doc : update guide and release notes for mlx5
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olga Shern > Sent: Tuesday, July 26, 2016 5:29 PM > To: dev at dpdk.org > Cc: Olga Shern > Subject: [dpdk-dev] [PATCH] doc : update guide and release notes for mlx5 > > ... > > +* **Updated the mlx5 driver.** > + > + The mlx5 driver was updated with changes including the following: > + > + * Data path was refactored to bypass Verbs to improve RX and TX > performance. > + * Removed compilation parameters for inline send, MLX5_MAX_INLINE, and > +added command line parameter instead, txq_inline. > + * Improved TX scatter gather support: > +Removed compilation parameter MLX5_PMD_SGE_WR_N. > +Scatter-gather elements is set to the maximum value the NIC supports. > +Removed linearization logic, this decreases the memory consumption of > the PMD. > + * Improved jumbo frames support, by dynamically setting RX scatter > gather elements > +according to the MTU and mbuf size, > +no need for compilation parameter MLX5_PMD_SGE_WR_N. > + Hi, There are 2 whitespace warnings in the patch. If you resubmit can you also put the MLX5 variables in fixed width quotes. Apart from that: Acked-by: John McNamara
[dpdk-dev] [PATCH v4] doc: add section on tested platforms and nics and OSes
> -Original Message- > From: Pei, Yulong > Sent: Wednesday, July 27, 2016 4:14 AM > To: dev at dpdk.org; thomas.monjalon at 6wind.com > Cc: Mcnamara, John ; Pei, Yulong > > Subject: [PATCH v4] doc: add section on tested platforms and nics and OSes > > Add new section on tested platforms and nics and OSes to the release > notes. > > ... > > +Tested OSes > +--- > + > +.. This section should contain a list of OSes that were tested with this > release. > + > + - CentOS 7.0 > + - Fedora 23 > + - Fedora 24 > + - FreeBSD 10.3 > + - Red Hat Enterprise Linux 7.2 > + - SUSE Enterprise Linux 12 > + - Ubuntu 15.10 > + - Ubuntu 16.04 LTS > + - Wind River Linux 8 > + Unfortunately, the list of OSes is at the same indentation level as the comment so it is parsed as a comment and isn't visible in the final doc. You can check the doc output as follows: make doc-guides-html -j firefox build/doc/html/guides/rel_notes/release_16_07.html & Just remove the leading whitespace at the start of the list. Sorry for the rework. John
[dpdk-dev] [PATCH v3] doc: add known issue about promiscuous mode for I40e VF
> -Original Message- > From: Guo, Jia > Sent: Wednesday, July 27, 2016 3:57 AM > To: Mcnamara, John > Cc: dev at dpdk.org; Guo, Jia > Subject: [PATCH v3] doc: add known issue about promiscuous mode for I40e > VF > > When use i40e linux kernel driver as host driver and DPDK handler the i40e > VF, the promiscuous mode doesn't work in i40e VF. It is not supported by > DPDK i40e VF driver right now. > > Signed-off-by: Jeff Guo Acked-by: John McNamara
[dpdk-dev] [PATCH] examples/ip_pipeline: fix wrong values in flow.cfg
This configuration is example configuration for flow classification.
This fix changes the offset and mask value to compute the hash correctly.
This fix does not involve code change and do not impact compilation,
build and performance.
Fixes: 93771a569daa ("examples/ip_pipeline: rework flow classification CLI")
Signed-off-by: Sankar Chokkalingam
Acked-by: Cristian Dumitrescu
---
examples/ip_pipeline/config/flow.cfg | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/examples/ip_pipeline/config/flow.cfg
b/examples/ip_pipeline/config/flow.cfg
index 6895d39..cec990a 100644
--- a/examples/ip_pipeline/config/flow.cfg
+++ b/examples/ip_pipeline/config/flow.cfg
@@ -64,8 +64,8 @@ pktq_in = RXQ0.0 RXQ1.0 RXQ2.0 RXQ3.0
pktq_out = TXQ0.0 TXQ1.0 TXQ2.0 TXQ3.0 SINK0
n_flows = 65536
;key_size = 8; QinQ key size
-;key_offset = 270; QinQ key offset
-;key_mask = FFF0FFF0 ; QinQ key mask
+;key_offset = 268; QinQ key offset
+;key_mask = 0FFF0FFF ; QinQ key mask
key_size = 16 ; IPv4 5-tuple key size
key_offset = 278; IPv4 5-tuple key offset
key_mask = 00FF ; IPv4 5-tuple key mask
--
2.5.5
[dpdk-dev] [PATCH v2] doc: announce ABI change for rte_eth_dev structure
> > Signed-off-by: Tomasz Kulasek > > --- > > +* In 16.11 ABI changes are plained: the ``rte_eth_dev`` structure will be > > + extended with new function pointer ``tx_pkt_prep`` allowing verification > > + and processing of packet burst to meet HW specific requirements before > > + transmit. Also new fields will be added to the ``rte_eth_desc_lim`` > > structure: > > + ``nb_seg_max`` and ``nb_mtu_seg_max`` provideing information about > > number of > > + segments limit to be transmitted by device for TSO/non-TSO packets. > > Acked-by: Konstantin Ananyev I think I understand you want to split the TX processing: 1/ modify/write in mbufs 2/ write in HW and let application decide: - where the TX prep is done (which core) - what to do if the TX prep fail So adding some processing in this first part becomes "not too expensive" or "manageable" from the application point of view. If I well understand the intent, Acked-by: Thomas Monjalon (except typos ;)
