[dpdk-dev] Compiling MLX4 Support into 2.1.0

[Adrien Mazarguil]

On Fri, Sep 11, 2015 at 09:51:19AM -0700, Nathan Speulda wrote:
> Thank you for the response,
> 
> I followed all of the documentation before I came to the forum on this
> one.  OFED is installed and working correctly with all drivers loaded.  I
> get to the point of compiling dpdk with support enabled and nothing appears
> to come out during the compile (for mlx4 which is included in the
> .config).  My interfaces are not being seen by the PMD though I am aware it
> works differently than the base supported adapters.

I understand you do not see anything like the following lines while DPDK is
being compiled?

 == BUILD drivers/net/mlx4
   CC mlx4.o
   AR librte_pmd_mlx4.a
   INSTALL-LIB librte_pmd_mlx4.a

If you don't, something is wrong in your .config, perhaps you haven't
edited the right one? Depending on your target, DPDK may generate another
with default options in an unexpected place and use it instead of your own.

Otherwise, I suggest following Olga's advice, your ports may not be in the
right mode (IB instead of Ethernet), or you're using the wrong kernel
modules in which case mlx4 usually complains during startup.

This is only a guess, please provide compilation, program (testpmd?) startup
logs and the related command line if it still doesn't work.

-- 
Adrien Mazarguil
6WIND

[dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1 for all NICs but 82598

[Avi Kivity]

On 09/11/2015 07:08 PM, Thomas Monjalon wrote:
> 2015-09-11 18:43, Avi Kivity:
>> On 09/11/2015 06:12 PM, Vladislav Zolotarov wrote:
>>> On Sep 11, 2015 5:55 PM, "Thomas Monjalon" >> > wrote:
 2015-09-11 17:47, Avi Kivity:
> On 09/11/2015 05:25 PM, didier.pallard wrote:
>> Hi vlad,
>>
>> Documentation states that a packet (or multiple packets in transmit
>> segmentation) can span any number of
>> buffers (and their descriptors) up to a limit of 40 minus WTHRESH
>> minus 2.
>>
>> Shouldn't there be a test in transmit function that drops
>>> properly the
>> mbufs with a too large number of
>> segments, while incrementing a statistic; otherwise transmit
>>> function
>> may be locked by the faulty packet without
>> notification.
>>
> What we proposed is that the pmd expose to dpdk, and dpdk expose
>>> to the
> application, an mbuf check function.  This way applications that can
> generate complex packets can verify that the device will be able to
> process them, and applications that only generate simple mbufs can
>>> avoid
> the overhead by not calling the function.
 More than a check, it should be exposed as a capability of the port.
 Anyway, if the application sends too much segments, the driver must
 drop it to avoid hang, and maintain a dedicated statistic counter to
 allow easy debugging.
>>> I agree with Thomas - this should not be optional. Malformed packets
>>> should be dropped. In the icgbe case it's a very simple test - it's a
>>> single branch per packet so i doubt that it could impose any
>>> measurable performance degradation.
>> A drop allows the application no chance to recover.  The driver must
>> either provide the ability for the application to know that it cannot
>> accept the packet, or it must fix it up itself.
> I have the feeling that everybody agrees on the same thing:
> the application must be able to make a well formed packet by checking
> limitations of the port. What about a field rte_eth_dev_info.max_tx_segs?

It is not generic enough.  i40e has a limit that it imposes post-TSO.


> In case the application fails in its checks, the driver must drop it and
> notify the user via a stat counter.
> The driver can also remove the hardware limitation by gathering the segments
> but it may be hard to implement and would be a slow operation.

I think that to satisfy both the 64b full line rate applications and the 
more complicated full stack applications, this must be made optional.  
In particular, and application that only forwards packets will never hit 
a NIC's limits, so it need not take any action. That's why I think a 
verification function is ideal; a forwarding application can ignore it, 
and a complex application can call it, and if it fails the packet, it 
can linearize it itself, removing complexity from dpdk itself.

[dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1 for all NICs but 82598

[Avi Kivity]

On 09/11/2015 07:07 PM, Richardson, Bruce wrote:
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Vladislav Zolotarov
>> Sent: Friday, September 11, 2015 5:04 PM
>> To: Avi Kivity
>> Cc: dev at dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1
>> for all NICs but 82598
>>
>> On Sep 11, 2015 6:43 PM, "Avi Kivity"  wrote:
>>> On 09/11/2015 06:12 PM, Vladislav Zolotarov wrote:

 On Sep 11, 2015 5:55 PM, "Thomas Monjalon"
 
>> wrote:
> 2015-09-11 17:47, Avi Kivity:
>> On 09/11/2015 05:25 PM, didier.pallard wrote:
>>> On 08/25/2015 08:52 PM, Vlad Zolotarov wrote:
 Helin, the issue has been seen on x540 devices. Pls., see a
>> chapter
 7.2.1.1 of x540 devices spec:

 A packet (or multiple packets in transmit segmentation) can
 span
>> any
 number of
 buffers (and their descriptors) up to a limit of 40 minus
 WTHRESH minus 2 (see Section 7.2.3.3 for Tx Ring details and
 section Section 7.2.3.5.1
>> for
 WTHRESH
 details). For best performance it is recommended to minimize
 the number of buffers as possible.

 Could u, pls., clarify why do u think that the maximum number
 of
>> data
 buffers is limited by 8?

 thanks,
 vlad
>>> Hi vlad,
>>>
>>> Documentation states that a packet (or multiple packets in
>>> transmit
>>> segmentation) can span any number of buffers (and their
>>> descriptors) up to a limit of 40 minus WTHRESH minus 2.
>>>
>>> Shouldn't there be a test in transmit function that drops
>>> properly
>> the
>>> mbufs with a too large number of segments, while incrementing a
>>> statistic; otherwise transmit
>> function
>>> may be locked by the faulty packet without notification.
>>>
>> What we proposed is that the pmd expose to dpdk, and dpdk expose
>> to
>> the
>> application, an mbuf check function.  This way applications that
>> can generate complex packets can verify that the device will be
>> able to process them, and applications that only generate simple
>> mbufs can
>> avoid
>> the overhead by not calling the function.
> More than a check, it should be exposed as a capability of the port.
> Anyway, if the application sends too much segments, the driver must
> drop it to avoid hang, and maintain a dedicated statistic counter
> to
>> allow
> easy debugging.
 I agree with Thomas - this should not be optional. Malformed packets
>> should be dropped. In the icgbe case it's a very simple test - it's a
>> single branch per packet so i doubt that it could impose any measurable
>> performance degradation.allows

>>> A drop allows the application no chance to recover.  The driver must
>> either provide the ability for the application to know that it cannot
>> accept the packet, or it must fix it up itself.
>>
>> An appropriate statistics counter would be a perfect tool to detect such
>> issues. Knowingly sending a packet that will cause a HW to hang is not
>> acceptable.
> I would agree. Drivers should provide a function to query the max number of
> segments they can accept and the driver should be able to discard any packets
> exceeding that number, and just track it via a stat.
>

There is no such max number of segments.  The i40e card, as an extreme 
example, allows 8 fragments per packet, but that is after TSO 
segmentation.  So if the header is in three fragments, that leaves 5 
data fragments per packet.  Another card (ixgbe) has a 38-fragment 
pre-TSO limit.  With such a variety of limitations, the only generic way 
to expose them is via a function.

[dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1 for all NICs but 82598

[Vladislav Zolotarov]

On Sep 11, 2015 7:09 PM, "Thomas Monjalon" 
wrote:
>
> 2015-09-11 18:43, Avi Kivity:
> > On 09/11/2015 06:12 PM, Vladislav Zolotarov wrote:
> > > On Sep 11, 2015 5:55 PM, "Thomas Monjalon"  > > > wrote:
> > > > 2015-09-11 17:47, Avi Kivity:
> > > > > On 09/11/2015 05:25 PM, didier.pallard wrote:
> > > > > > Hi vlad,
> > > > > >
> > > > > > Documentation states that a packet (or multiple packets in
transmit
> > > > > > segmentation) can span any number of
> > > > > > buffers (and their descriptors) up to a limit of 40 minus
WTHRESH
> > > > > > minus 2.
> > > > > >
> > > > > > Shouldn't there be a test in transmit function that drops
> > > properly the
> > > > > > mbufs with a too large number of
> > > > > > segments, while incrementing a statistic; otherwise transmit
> > > function
> > > > > > may be locked by the faulty packet without
> > > > > > notification.
> > > > > >
> > > > >
> > > > > What we proposed is that the pmd expose to dpdk, and dpdk expose
> > > to the
> > > > > application, an mbuf check function.  This way applications that
can
> > > > > generate complex packets can verify that the device will be able
to
> > > > > process them, and applications that only generate simple mbufs can
> > > avoid
> > > > > the overhead by not calling the function.
> > > >
> > > > More than a check, it should be exposed as a capability of the port.
> > > > Anyway, if the application sends too much segments, the driver must
> > > > drop it to avoid hang, and maintain a dedicated statistic counter to
> > > > allow easy debugging.
> > >
> > > I agree with Thomas - this should not be optional. Malformed packets
> > > should be dropped. In the icgbe case it's a very simple test - it's a
> > > single branch per packet so i doubt that it could impose any
> > > measurable performance degradation.
> >
> > A drop allows the application no chance to recover.  The driver must
> > either provide the ability for the application to know that it cannot
> > accept the packet, or it must fix it up itself.
>
> I have the feeling that everybody agrees on the same thing:
> the application must be able to make a well formed packet by checking
> limitations of the port. What about a field rte_eth_dev_info.max_tx_segs?
> In case the application fails in its checks, the driver must drop it and
> notify the user via a stat counter.
> The driver can also remove the hardware limitation by gathering the
segments
> but it may be hard to implement and would be a slow operation.

We thought about linearization too. It's doable with extra mempool and it
may be optional so that those that don't need could compile it out and/or
disable it in a runtime...

[dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1 for all NICs but 82598

[Vladislav Zolotarov]

On Sep 11, 2015 7:07 PM, "Richardson, Bruce" 
wrote:
>
>
>
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Vladislav Zolotarov
> > Sent: Friday, September 11, 2015 5:04 PM
> > To: Avi Kivity
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above
1
> > for all NICs but 82598
> >
> > On Sep 11, 2015 6:43 PM, "Avi Kivity"  wrote:
> > >
> > > On 09/11/2015 06:12 PM, Vladislav Zolotarov wrote:
> > >>
> > >>
> > >> On Sep 11, 2015 5:55 PM, "Thomas Monjalon"
> > >> 
> > wrote:
> > >> >
> > >> > 2015-09-11 17:47, Avi Kivity:
> > >> > > On 09/11/2015 05:25 PM, didier.pallard wrote:
> > >> > > > On 08/25/2015 08:52 PM, Vlad Zolotarov wrote:
> > >> > > >>
> > >> > > >> Helin, the issue has been seen on x540 devices. Pls., see a
> > chapter
> > >> > > >> 7.2.1.1 of x540 devices spec:
> > >> > > >>
> > >> > > >> A packet (or multiple packets in transmit segmentation) can
> > >> > > >> span
> > any
> > >> > > >> number of
> > >> > > >> buffers (and their descriptors) up to a limit of 40 minus
> > >> > > >> WTHRESH minus 2 (see Section 7.2.3.3 for Tx Ring details and
> > >> > > >> section Section 7.2.3.5.1
> > for
> > >> > > >> WTHRESH
> > >> > > >> details). For best performance it is recommended to minimize
> > >> > > >> the number of buffers as possible.
> > >> > > >>
> > >> > > >> Could u, pls., clarify why do u think that the maximum number
> > >> > > >> of
> > data
> > >> > > >> buffers is limited by 8?
> > >> > > >>
> > >> > > >> thanks,
> > >> > > >> vlad
> > >> > > >
> > >> > > > Hi vlad,
> > >> > > >
> > >> > > > Documentation states that a packet (or multiple packets in
> > >> > > > transmit
> > >> > > > segmentation) can span any number of buffers (and their
> > >> > > > descriptors) up to a limit of 40 minus WTHRESH minus 2.
> > >> > > >
> > >> > > > Shouldn't there be a test in transmit function that drops
> > >> > > > properly
> > the
> > >> > > > mbufs with a too large number of segments, while incrementing a
> > >> > > > statistic; otherwise transmit
> > function
> > >> > > > may be locked by the faulty packet without notification.
> > >> > > >
> > >> > >
> > >> > > What we proposed is that the pmd expose to dpdk, and dpdk expose
> > >> > > to
> > the
> > >> > > application, an mbuf check function.  This way applications that
> > >> > > can generate complex packets can verify that the device will be
> > >> > > able to process them, and applications that only generate simple
> > >> > > mbufs can
> > avoid
> > >> > > the overhead by not calling the function.
> > >> >
> > >> > More than a check, it should be exposed as a capability of the
port.
> > >> > Anyway, if the application sends too much segments, the driver must
> > >> > drop it to avoid hang, and maintain a dedicated statistic counter
> > >> > to
> > allow
> > >> > easy debugging.
> > >>
> > >> I agree with Thomas - this should not be optional. Malformed packets
> > should be dropped. In the icgbe case it's a very simple test - it's a
> > single branch per packet so i doubt that it could impose any measurable
> > performance degradation.
> > >>
> > >>
> > >
> > > A drop allows the application no chance to recover.  The driver must
> > either provide the ability for the application to know that it cannot
> > accept the packet, or it must fix it up itself.
> >
> > An appropriate statistics counter would be a perfect tool to detect such
> > issues. Knowingly sending a packet that will cause a HW to hang is not
> > acceptable.
>
> I would agree. Drivers should provide a function to query the max number
of
> segments they can accept and the driver should be able to discard any
packets
> exceeding that number, and just track it via a stat.

+1

>
> /Bruce

[dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1 for all NICs but 82598

[Vladislav Zolotarov]

On Sep 11, 2015 7:00 PM, "Richardson, Bruce" 
wrote:
>
>
>
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Vladislav Zolotarov
> > Sent: Friday, September 11, 2015 4:13 PM
> > To: Thomas Monjalon
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above
1
> > for all NICs but 82598
> >
> > On Sep 11, 2015 5:55 PM, "Thomas Monjalon" 
> > wrote:
> > >
> > > 2015-09-11 17:47, Avi Kivity:
> > > > On 09/11/2015 05:25 PM, didier.pallard wrote:
> > > > > On 08/25/2015 08:52 PM, Vlad Zolotarov wrote:
> > > > >>
> > > > >> Helin, the issue has been seen on x540 devices. Pls., see a
> > > > >> chapter
> > > > >> 7.2.1.1 of x540 devices spec:
> > > > >>
> > > > >> A packet (or multiple packets in transmit segmentation) can span
> > > > >> any number of buffers (and their descriptors) up to a limit of 40
> > > > >> minus WTHRESH minus 2 (see Section 7.2.3.3 for Tx Ring details
> > > > >> and section Section 7.2.3.5.1 for WTHRESH details). For best
> > > > >> performance it is recommended to minimize the number of buffers
> > > > >> as possible.
> > > > >>
> > > > >> Could u, pls., clarify why do u think that the maximum number of
> > > > >> data buffers is limited by 8?
> > > > >>
> > > > >> thanks,
> > > > >> vlad
> > > > >
> > > > > Hi vlad,
> > > > >
> > > > > Documentation states that a packet (or multiple packets in
> > > > > transmit
> > > > > segmentation) can span any number of buffers (and their
> > > > > descriptors) up to a limit of 40 minus WTHRESH minus 2.
> > > > >
> > > > > Shouldn't there be a test in transmit function that drops properly
> > > > > the mbufs with a too large number of segments, while incrementing
> > > > > a statistic; otherwise transmit function may be locked by the
> > > > > faulty packet without notification.
> > > > >
> > > >
> > > > What we proposed is that the pmd expose to dpdk, and dpdk expose to
> > > > the application, an mbuf check function.  This way applications that
> > > > can generate complex packets can verify that the device will be able
> > > > to process them, and applications that only generate simple mbufs
> > > > can avoid the overhead by not calling the function.
> > >
> > > More than a check, it should be exposed as a capability of the port.
> > > Anyway, if the application sends too much segments, the driver must
> > > drop it to avoid hang, and maintain a dedicated statistic counter to
> > > allow easy debugging.
> >
> > I agree with Thomas - this should not be optional. Malformed packets
> > should be dropped. In the icgbe case it's a very simple test - it's a
> > single branch per packet so i doubt that it could impose any measurable
> > performance degradation.
> >
> Actually, it could very well do - we'd have to test it. For the vector IO
> paths, every additional cycle in the RX or TX paths causes a noticeable
perf
> drop.

Well if your application is willing to know all different HW limitations
then u may not need it. However usually application doesn't want to know
the HW technical details. And it this case ignoring them may cause HW to
hang.

Of course, if your app always sends single fragment packets of less than
1500 bytes then u r right and u will most likely not hit any HW limitation,
however what i have in mind is a full featured case where packets are bit
more big and complicated and where a single branch per packet will change
nothing. This is regarding 40 segments case.

In regard to the RS bit - this is related to any packet and according to
spec it should be set in every packet.

>
> /Bruce

[dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1 for all NICs but 82598

[Vladislav Zolotarov]

On Sep 11, 2015 6:43 PM, "Avi Kivity"  wrote:
>
> On 09/11/2015 06:12 PM, Vladislav Zolotarov wrote:
>>
>>
>> On Sep 11, 2015 5:55 PM, "Thomas Monjalon" 
wrote:
>> >
>> > 2015-09-11 17:47, Avi Kivity:
>> > > On 09/11/2015 05:25 PM, didier.pallard wrote:
>> > > > On 08/25/2015 08:52 PM, Vlad Zolotarov wrote:
>> > > >>
>> > > >> Helin, the issue has been seen on x540 devices. Pls., see a
chapter
>> > > >> 7.2.1.1 of x540 devices spec:
>> > > >>
>> > > >> A packet (or multiple packets in transmit segmentation) can span
any
>> > > >> number of
>> > > >> buffers (and their descriptors) up to a limit of 40 minus WTHRESH
>> > > >> minus 2 (see
>> > > >> Section 7.2.3.3 for Tx Ring details and section Section 7.2.3.5.1
for
>> > > >> WTHRESH
>> > > >> details). For best performance it is recommended to minimize the
>> > > >> number of buffers
>> > > >> as possible.
>> > > >>
>> > > >> Could u, pls., clarify why do u think that the maximum number of
data
>> > > >> buffers is limited by 8?
>> > > >>
>> > > >> thanks,
>> > > >> vlad
>> > > >
>> > > > Hi vlad,
>> > > >
>> > > > Documentation states that a packet (or multiple packets in transmit
>> > > > segmentation) can span any number of
>> > > > buffers (and their descriptors) up to a limit of 40 minus WTHRESH
>> > > > minus 2.
>> > > >
>> > > > Shouldn't there be a test in transmit function that drops properly
the
>> > > > mbufs with a too large number of
>> > > > segments, while incrementing a statistic; otherwise transmit
function
>> > > > may be locked by the faulty packet without
>> > > > notification.
>> > > >
>> > >
>> > > What we proposed is that the pmd expose to dpdk, and dpdk expose to
the
>> > > application, an mbuf check function.  This way applications that can
>> > > generate complex packets can verify that the device will be able to
>> > > process them, and applications that only generate simple mbufs can
avoid
>> > > the overhead by not calling the function.
>> >
>> > More than a check, it should be exposed as a capability of the port.
>> > Anyway, if the application sends too much segments, the driver must
>> > drop it to avoid hang, and maintain a dedicated statistic counter to
allow
>> > easy debugging.
>>
>> I agree with Thomas - this should not be optional. Malformed packets
should be dropped. In the icgbe case it's a very simple test - it's a
single branch per packet so i doubt that it could impose any measurable
performance degradation.
>>
>>
>
> A drop allows the application no chance to recover.  The driver must
either provide the ability for the application to know that it cannot
accept the packet, or it must fix it up itself.

An appropriate statistics counter would be a perfect tool to detect such
issues. Knowingly sending a packet that will cause a HW to hang is not
acceptable.

[dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1 for all NICs but 82598

[Avi Kivity]

On 09/11/2015 06:12 PM, Vladislav Zolotarov wrote:
>
>
> On Sep 11, 2015 5:55 PM, "Thomas Monjalon"  > wrote:
> >
> > 2015-09-11 17:47, Avi Kivity:
> > > On 09/11/2015 05:25 PM, didier.pallard wrote:
> > > > On 08/25/2015 08:52 PM, Vlad Zolotarov wrote:
> > > >>
> > > >> Helin, the issue has been seen on x540 devices. Pls., see a chapter
> > > >> 7.2.1.1 of x540 devices spec:
> > > >>
> > > >> A packet (or multiple packets in transmit segmentation) can 
> span any
> > > >> number of
> > > >> buffers (and their descriptors) up to a limit of 40 minus WTHRESH
> > > >> minus 2 (see
> > > >> Section 7.2.3.3 for Tx Ring details and section Section 
> 7.2.3.5.1 for
> > > >> WTHRESH
> > > >> details). For best performance it is recommended to minimize the
> > > >> number of buffers
> > > >> as possible.
> > > >>
> > > >> Could u, pls., clarify why do u think that the maximum number 
> of data
> > > >> buffers is limited by 8?
> > > >>
> > > >> thanks,
> > > >> vlad
> > > >
> > > > Hi vlad,
> > > >
> > > > Documentation states that a packet (or multiple packets in transmit
> > > > segmentation) can span any number of
> > > > buffers (and their descriptors) up to a limit of 40 minus WTHRESH
> > > > minus 2.
> > > >
> > > > Shouldn't there be a test in transmit function that drops 
> properly the
> > > > mbufs with a too large number of
> > > > segments, while incrementing a statistic; otherwise transmit 
> function
> > > > may be locked by the faulty packet without
> > > > notification.
> > > >
> > >
> > > What we proposed is that the pmd expose to dpdk, and dpdk expose 
> to the
> > > application, an mbuf check function.  This way applications that can
> > > generate complex packets can verify that the device will be able to
> > > process them, and applications that only generate simple mbufs can 
> avoid
> > > the overhead by not calling the function.
> >
> > More than a check, it should be exposed as a capability of the port.
> > Anyway, if the application sends too much segments, the driver must
> > drop it to avoid hang, and maintain a dedicated statistic counter to 
> allow
> > easy debugging.
>
> I agree with Thomas - this should not be optional. Malformed packets 
> should be dropped. In the icgbe case it's a very simple test - it's a 
> single branch per packet so i doubt that it could impose any 
> measurable performance degradation.
>
>

A drop allows the application no chance to recover.  The driver must 
either provide the ability for the application to know that it cannot 
accept the packet, or it must fix it up itself.

[dpdk-dev] Compiling MLX4 Support into 2.1.0

[Adrien Mazarguil]

Hi Nathan,

On Fri, Sep 11, 2015 at 09:10:03AM -0700, Nathan Speulda wrote:
> All,
> 
> I am attempting to do some work using a CX3-Pro adapter in a forwarding
> environment and am attempting to enable the supported PMD that is included
> in the 2.1.0 release of DPDK.  My base distro is RHEL6.5 for stability
> reasons.  Does anyone have a more detailed idea of how to get the Mellanox
> PMD working correctly?  Does base distro have any impact on this at all?  I
> have been unable to find what I need at the Mellanox community support.

You need to install Mellanox OFED before attempting to compile the mlx4
PMD, as described in the relevant documentation (doc/guides/nics/mlx4.rst)
also available here:

 http://dpdk.org/doc/guides/nics/mlx4.html

See "Prerequisites" and "Getting Mellanox OFED" sections.

It should work fine with all Linux distributions supported by Mellanox
OFED. In your specific case, RHEL 6.5 is supported by MOFED 3.0-2.0.1.

-- 
Adrien Mazarguil
6WIND

[dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1 for all NICs but 82598

[Vladislav Zolotarov]

On Sep 9, 2015 4:19 PM, "Ananyev, Konstantin" 
wrote:
>
> Hi Thomas,
>
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> > Sent: Wednesday, September 09, 2015 1:19 PM
> > To: Zhang, Helin
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above
1 for all NICs but 82598
> >
> > 2015-08-25 20:13, Zhang, Helin:
> > > Yes, I got the perfect answers. Thank you very much!
> > > I just wanted to make sure the test case was OK with the limit of
maximum number of descriptors, as I heard there is a hang issue on
> > other NICs of using more descriptors than hardware allowed.
> > > OK. I am still waiting for the answers/confirmation from x540
hardware designers. We need all agree on your patches to avoid risks.
> >
> > Helin, any news?
> > Can we apply v4 of this patch?
>
> Unfortunately we are seeing a huge performance drop with that patch:
> On my box bi-directional traffic (64B packet) over one port can't reach
even 11 Mpps.

Konstantin, could u clarify - u saw "only" 11 Mpps with v3 of this patch
which doesn't change the rs_thresh and only sets RS on every packet? What
is the performance in the same test without this patch?

> We are still doing some experiments and consultations with ND guys how we
can overcome
> this problem and keep performance intact.
>
> Konstantin

[dpdk-dev] [PATCH 0/5] bnx2x: Enhancement, fixes, licensing and doumentation

[Stephen Hemminger]

On Fri, 11 Sep 2015 17:42:51 -0700
Rasesh Mody  wrote:

> Hi
> 
> This patch set consists of enhancements, fixes, licensing and
> documentation changes for the QLogic bnx2x Poll Mode Driver. The patches
> have been generated and tested against latest dpdk tree.
> 
> Please apply.
> 
> Thanks!
> Rasesh
> 
> Harish Patil (4):
>   bnx2x: SR-IOV VF driver changes to support OOB PF driver
>   bnx2x: Fix x86_64-native-linuxapp-clang build error
>   bnx2x: Add RTE_LIBRTE_BNX2X_REG_ACCESS config option
>   doc: Add BNX2X PMD documentation
> 
> Rasesh Mody (1):
>   bnx2x: Add LICENSE.bnx2x_pmd and update source files
> 
>  config/common_linuxapp  |1 +
>  doc/guides/nics/bnx2x.rst   |  324 
> +++
>  drivers/net/bnx2x/LICENSE.bnx2x_pmd |   28 +++
>  drivers/net/bnx2x/Makefile  |2 +-
>  drivers/net/bnx2x/bnx2x.c   |   29 +---
>  drivers/net/bnx2x/bnx2x.h   |   31 +---
>  drivers/net/bnx2x/bnx2x_ethdev.c|4 +
>  drivers/net/bnx2x/bnx2x_ethdev.h|4 +
>  drivers/net/bnx2x/bnx2x_logs.h  |   12 ++
>  drivers/net/bnx2x/bnx2x_rxtx.c  |4 +
>  drivers/net/bnx2x/bnx2x_rxtx.h  |4 +
>  drivers/net/bnx2x/bnx2x_stats.c |   27 +--
>  drivers/net/bnx2x/bnx2x_stats.h |   27 +--
>  drivers/net/bnx2x/bnx2x_vfpf.c  |   15 +-
>  drivers/net/bnx2x/bnx2x_vfpf.h  |   19 ++
>  drivers/net/bnx2x/debug.c   |   51 ++
>  drivers/net/bnx2x/ecore_fw_defs.h   |   27 +--
>  drivers/net/bnx2x/ecore_hsi.h   |   29 +---
>  drivers/net/bnx2x/ecore_init.h  |   27 +--
>  drivers/net/bnx2x/ecore_init_ops.h  |   27 +--
>  drivers/net/bnx2x/ecore_mfw_req.h   |   27 +--
>  drivers/net/bnx2x/ecore_reg.h   |   27 +--
>  drivers/net/bnx2x/ecore_sp.c|   27 +--
>  drivers/net/bnx2x/ecore_sp.h|   27 +--
>  drivers/net/bnx2x/elink.c   |   29 +---
>  drivers/net/bnx2x/elink.h   |   29 +---
>  26 files changed, 483 insertions(+), 375 deletions(-)
>  create mode 100644 doc/guides/nics/bnx2x.rst
>  create mode 100644 drivers/net/bnx2x/LICENSE.bnx2x_pmd


This part looks good. Could you send a patch to MAINTAINERS file
as well.

Acked-by: Stephen Hemminger 

[dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1 for all NICs but 82598

[Vladislav Zolotarov]

On Sep 11, 2015 5:55 PM, "Thomas Monjalon" 
wrote:
>
> 2015-09-11 17:47, Avi Kivity:
> > On 09/11/2015 05:25 PM, didier.pallard wrote:
> > > On 08/25/2015 08:52 PM, Vlad Zolotarov wrote:
> > >>
> > >> Helin, the issue has been seen on x540 devices. Pls., see a chapter
> > >> 7.2.1.1 of x540 devices spec:
> > >>
> > >> A packet (or multiple packets in transmit segmentation) can span any
> > >> number of
> > >> buffers (and their descriptors) up to a limit of 40 minus WTHRESH
> > >> minus 2 (see
> > >> Section 7.2.3.3 for Tx Ring details and section Section 7.2.3.5.1 for
> > >> WTHRESH
> > >> details). For best performance it is recommended to minimize the
> > >> number of buffers
> > >> as possible.
> > >>
> > >> Could u, pls., clarify why do u think that the maximum number of data
> > >> buffers is limited by 8?
> > >>
> > >> thanks,
> > >> vlad
> > >
> > > Hi vlad,
> > >
> > > Documentation states that a packet (or multiple packets in transmit
> > > segmentation) can span any number of
> > > buffers (and their descriptors) up to a limit of 40 minus WTHRESH
> > > minus 2.
> > >
> > > Shouldn't there be a test in transmit function that drops properly the
> > > mbufs with a too large number of
> > > segments, while incrementing a statistic; otherwise transmit function
> > > may be locked by the faulty packet without
> > > notification.
> > >
> >
> > What we proposed is that the pmd expose to dpdk, and dpdk expose to the
> > application, an mbuf check function.  This way applications that can
> > generate complex packets can verify that the device will be able to
> > process them, and applications that only generate simple mbufs can avoid
> > the overhead by not calling the function.
>
> More than a check, it should be exposed as a capability of the port.
> Anyway, if the application sends too much segments, the driver must
> drop it to avoid hang, and maintain a dedicated statistic counter to allow
> easy debugging.

I agree with Thomas - this should not be optional. Malformed packets should
be dropped. In the icgbe case it's a very simple test - it's a single
branch per packet so i doubt that it could impose any measurable
performance degradation.

>

[dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1 for all NICs but 82598

[Thomas Monjalon]

2015-09-11 18:43, Avi Kivity:
> On 09/11/2015 06:12 PM, Vladislav Zolotarov wrote:
> > On Sep 11, 2015 5:55 PM, "Thomas Monjalon"  > > wrote:
> > > 2015-09-11 17:47, Avi Kivity:
> > > > On 09/11/2015 05:25 PM, didier.pallard wrote:
> > > > > Hi vlad,
> > > > >
> > > > > Documentation states that a packet (or multiple packets in transmit
> > > > > segmentation) can span any number of
> > > > > buffers (and their descriptors) up to a limit of 40 minus WTHRESH
> > > > > minus 2.
> > > > >
> > > > > Shouldn't there be a test in transmit function that drops 
> > properly the
> > > > > mbufs with a too large number of
> > > > > segments, while incrementing a statistic; otherwise transmit 
> > function
> > > > > may be locked by the faulty packet without
> > > > > notification.
> > > > >
> > > >
> > > > What we proposed is that the pmd expose to dpdk, and dpdk expose 
> > to the
> > > > application, an mbuf check function.  This way applications that can
> > > > generate complex packets can verify that the device will be able to
> > > > process them, and applications that only generate simple mbufs can 
> > avoid
> > > > the overhead by not calling the function.
> > >
> > > More than a check, it should be exposed as a capability of the port.
> > > Anyway, if the application sends too much segments, the driver must
> > > drop it to avoid hang, and maintain a dedicated statistic counter to 
> > > allow easy debugging.
> >
> > I agree with Thomas - this should not be optional. Malformed packets 
> > should be dropped. In the icgbe case it's a very simple test - it's a 
> > single branch per packet so i doubt that it could impose any 
> > measurable performance degradation.
> 
> A drop allows the application no chance to recover.  The driver must 
> either provide the ability for the application to know that it cannot 
> accept the packet, or it must fix it up itself.

I have the feeling that everybody agrees on the same thing:
the application must be able to make a well formed packet by checking
limitations of the port. What about a field rte_eth_dev_info.max_tx_segs?
In case the application fails in its checks, the driver must drop it and
notify the user via a stat counter.
The driver can also remove the hardware limitation by gathering the segments
but it may be hard to implement and would be a slow operation.

[dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1 for all NICs but 82598

[Avi Kivity]

On 09/11/2015 05:25 PM, didier.pallard wrote:
> On 08/25/2015 08:52 PM, Vlad Zolotarov wrote:
>>
>> Helin, the issue has been seen on x540 devices. Pls., see a chapter 
>> 7.2.1.1 of x540 devices spec:
>>
>> A packet (or multiple packets in transmit segmentation) can span any 
>> number of
>> buffers (and their descriptors) up to a limit of 40 minus WTHRESH 
>> minus 2 (see
>> Section 7.2.3.3 for Tx Ring details and section Section 7.2.3.5.1 for 
>> WTHRESH
>> details). For best performance it is recommended to minimize the 
>> number of buffers
>> as possible.
>>
>> Could u, pls., clarify why do u think that the maximum number of data 
>> buffers is limited by 8?
>>
>> thanks,
>> vlad
>
> Hi vlad,
>
> Documentation states that a packet (or multiple packets in transmit 
> segmentation) can span any number of
> buffers (and their descriptors) up to a limit of 40 minus WTHRESH 
> minus 2.
>
> Shouldn't there be a test in transmit function that drops properly the 
> mbufs with a too large number of
> segments, while incrementing a statistic; otherwise transmit function 
> may be locked by the faulty packet without
> notification.
>

What we proposed is that the pmd expose to dpdk, and dpdk expose to the 
application, an mbuf check function.  This way applications that can 
generate complex packets can verify that the device will be able to 
process them, and applications that only generate simple mbufs can avoid 
the overhead by not calling the function.

[dpdk-dev] [PATCH 5/5] bnx2x: Add LICENSE.bnx2x_pmd and update source files

[Rasesh Mody]

Signed-off-by: Rasesh Mody 
---
 drivers/net/bnx2x/LICENSE.bnx2x_pmd |   28 
 drivers/net/bnx2x/bnx2x.c   |   29 -
 drivers/net/bnx2x/bnx2x.h   |   29 -
 drivers/net/bnx2x/bnx2x_ethdev.c|4 
 drivers/net/bnx2x/bnx2x_ethdev.h|4 
 drivers/net/bnx2x/bnx2x_logs.h  |4 
 drivers/net/bnx2x/bnx2x_rxtx.c  |4 
 drivers/net/bnx2x/bnx2x_rxtx.h  |4 
 drivers/net/bnx2x/bnx2x_stats.c |   27 +++
 drivers/net/bnx2x/bnx2x_stats.h |   27 +++
 drivers/net/bnx2x/bnx2x_vfpf.c  |4 
 drivers/net/bnx2x/bnx2x_vfpf.h  |4 
 drivers/net/bnx2x/debug.c   |   27 +++
 drivers/net/bnx2x/ecore_fw_defs.h   |   27 ---
 drivers/net/bnx2x/ecore_hsi.h   |   27 ---
 drivers/net/bnx2x/ecore_init.h  |   27 +++
 drivers/net/bnx2x/ecore_init_ops.h  |   27 +++
 drivers/net/bnx2x/ecore_mfw_req.h   |   27 ---
 drivers/net/bnx2x/ecore_reg.h   |   27 ---
 drivers/net/bnx2x/ecore_sp.c|   27 +++
 drivers/net/bnx2x/ecore_sp.h|   27 +++
 drivers/net/bnx2x/elink.c   |   29 -
 drivers/net/bnx2x/elink.h   |   29 -
 23 files changed, 109 insertions(+), 360 deletions(-)
 create mode 100644 drivers/net/bnx2x/LICENSE.bnx2x_pmd

diff --git a/drivers/net/bnx2x/LICENSE.bnx2x_pmd 
b/drivers/net/bnx2x/LICENSE.bnx2x_pmd
new file mode 100644
index 000..96c7c1e
--- /dev/null
+++ b/drivers/net/bnx2x/LICENSE.bnx2x_pmd
@@ -0,0 +1,28 @@
+/*
+ * BSD LICENSE
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of Broadcom Corporation nor the name of its contributors
+ *may be used to endorse or promote products derived from this software
+ *without specific prior written consent.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS'
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS
+ * BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
+ * THE POSSIBILITY OF SUCH DAMAGE.
+ */
diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c
index fed7a06..1fa2492 100644
--- a/drivers/net/bnx2x/bnx2x.c
+++ b/drivers/net/bnx2x/bnx2x.c
@@ -1,37 +1,16 @@
 /*-
- * Copyright (c) 2007-2013 QLogic Corporation. All rights reserved.
+ * Copyright (c) 2007-2013 Broadcom Corporation.
  *
  * Eric Davis
  * David Christensen 
  * Gary Zambrano 
  *
  * Copyright (c) 2013-2015 Brocade Communications Systems, Inc.
+ * Copyright (c) 2015 QLogic Corporation.
  * All rights reserved.
+ * www.qlogic.com
  *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- *
- * 1. Redistributions of source code must retain the above copyright
- *notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *notice, this list of conditions and the following disclaimer in the
- *documentation and/or other materials provided with the distribution.
- * 3. Neither the name of Broadcom Corporation nor the name of its contributors
- *may be used to endorse or promote products derived from this software
- *without specific prior written consent.
- *
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS'
- * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED.  IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS
- * BE 

[dpdk-dev] [PATCH 4/5] doc: Add BNX2X PMD documentation

[Rasesh Mody]

From: Harish Patil 

Signed-off-by: Harish Patil 
---
 doc/guides/nics/bnx2x.rst |  324 +
 1 file changed, 324 insertions(+)
 create mode 100644 doc/guides/nics/bnx2x.rst

diff --git a/doc/guides/nics/bnx2x.rst b/doc/guides/nics/bnx2x.rst
new file mode 100644
index 000..613a2b7
--- /dev/null
+++ b/doc/guides/nics/bnx2x.rst
@@ -0,0 +1,324 @@
+..  BSD LICENSE
+Copyright (c) 2015 QLogic Corporation
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+* Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+* Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in
+the documentation and/or other materials provided with the
+distribution.
+* Neither the name of QLogic Corporation nor the names of its
+contributors may be used to endorse or promote products derived
+from this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+BNX2X Poll Mode Driver
+==
+
+The BNX2X poll mode driver library (**librte_pmd_bnx2x**) implemements support
+for **QLogic 578xx** 10/20 Gbps family of adapters as well as their virtual
+functions (VF) in SR-IOV context. It is supported on several standard Linux
+distros like Red Hat 7.x and SLES12 OS. It is compile-tested under FreeBSD OS.
+
+More information can be found at `QLogic Corporation's Official Website
+`_.
+
+Supported Features
+--
+
+BNX2X PMD has support for:
+
+- Base L2 features
+- Unicast/multicast filtering
+- Promiscuous mode
+- Port hardware statistics
+- SR-IOV VF
+
+Non-supported Features
+--
+
+The features not yet supported include:
+
+- TSS (Transmit Side Scaling)
+- RSS (Receive Side Scaling)
+- LRO/TSO offload
+- Checksum offload
+- SR-IOV PF
+
+Co-existence considerations
+---
+
+- BCM578xx being a CNA can have both NIC and Storage personalities.
+However, coexistence with storage protocol drivers (cnic, bnx2fc and
+bnx2fi) is not supported on the same adapter. So storage personality
+has to be disabled on that adapter when used in DPDK applications.
+
+- For SR-IOV case, bnx2x PMD will be used to bind to SR-IOV VF device and
+linux native kernel driver (bnx2x) will be attached to SR-IOV PF.
+
+
+Supported QLogic NICs
+-
+
+- 578xx
+
+Prerequisites
+-
+
+- Requires firmware version **7.2.51.0**. It is inbox on most of the
+  standard linux distros. If it is not available visit
+  `QLogic Driver Download Center `
+  to get the required firmware.
+
+Pre-Installation Configuration
+--
+
+Config File Options
+~~~
+
+The following options can be modified in the ``.config`` file. Please note that
+enabling debugging options may affect system performance.
+
+- ``CONFIG_RTE_LIBRTE_BNX2X_PMD`` (default **y**)
+
+  Toggle compilation of bnx2x driver.
+
+- ``CONFIG_RTE_LIBRTE_BNX2X_DEBUG`` (default **n**)
+
+  Toggle display of generic debugging messages.
+
+- ``CONFIG_RTE_LIBRTE_BNX2X_DEBUG_INIT`` (default **n**)
+
+  Toggle display of initialization related messages.
+
+- ``CONFIG_RTE_LIBRTE_BNX2X_DEBUG_TX`` (default **n**)
+
+  Toggle display of transmit fast path run-time messages.
+
+- ``CONFIG_RTE_LIBRTE_BNX2X_DEBUG_RX`` (default **n**)
+
+  Toggle display of receive fast path run-time messages.
+
+- ``CONFIG_RTE_LIBRTE_BNX2X_REG_ACCESS`` (default **n**)
+
+  Toggle display of register reads and writes.
+
+
+.. _driver-compilation:
+
+Driver Compilation
+~~
+
+To compile BNX2X PMD for Linux x86_64 gcc target, run the following "make"
+command:
+
+.. code-block:: console
+
+   cd 
+   make config T=x86_64-native-linuxapp-gcc install
+
+To compile BNX2X PMD for Linux x86_64 clang target, run the following "make"
+command:
+
+.. code-block:: console
+
+   

[dpdk-dev] [PATCH 3/5] bnx2x: Add RTE_LIBRTE_BNX2X_REG_ACCESS config option

[Rasesh Mody]

From: Harish Patil 

Signed-off-by: Harish Patil 
---
 config/common_linuxapp |1 +
 drivers/net/bnx2x/Makefile |2 +-
 drivers/net/bnx2x/bnx2x.h  |2 +-
 drivers/net/bnx2x/bnx2x_logs.h |8 
 drivers/net/bnx2x/debug.c  |   24 ++--
 5 files changed, 25 insertions(+), 12 deletions(-)

diff --git a/config/common_linuxapp b/config/common_linuxapp
index 0de43d5..013fa0d 100644
--- 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

 #
 # Compile burst-oriented Chelsio Terminator 10GbE/40GbE (CXGBE) PMD
diff --git a/drivers/net/bnx2x/Makefile b/drivers/net/bnx2x/Makefile
index 87f31b6..6b2df22 100644
--- a/drivers/net/bnx2x/Makefile
+++ b/drivers/net/bnx2x/Makefile
@@ -23,7 +23,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_BNX2X_PMD) += bnx2x_ethdev.c
 SRCS-$(CONFIG_RTE_LIBRTE_BNX2X_PMD) += ecore_sp.c
 SRCS-$(CONFIG_RTE_LIBRTE_BNX2X_PMD) += elink.c
 SRCS-$(CONFIG_RTE_LIBRTE_BNX2X_PMD) += bnx2x_vfpf.c
-SRCS-$(CONFIG_RTE_LIBRTE_BNX2X_DEBUG) += debug.c
+SRCS-$(CONFIG_RTE_LIBRTE_BNX2X_REG_ACCESS) += debug.c

 # this lib depends upon:
 DEPDIRS-$(CONFIG_RTE_LIBRTE_BNX2X_PMD) += lib/librte_eal lib/librte_ether 
lib/librte_hash
diff --git a/drivers/net/bnx2x/bnx2x.h b/drivers/net/bnx2x/bnx2x.h
index 867b92a..ffd101c 100644
--- a/drivers/net/bnx2x/bnx2x.h
+++ b/drivers/net/bnx2x/bnx2x.h
@@ -1445,7 +1445,7 @@ struct bnx2x_func_init_params {
 #define BAR1 2
 #define BAR2 4

-#ifdef RTE_LIBRTE_BNX2X_DEBUG
+#ifdef RTE_LIBRTE_BNX2X_REG_ACCESS
 uint8_t bnx2x_reg_read8(struct bnx2x_softc *sc, size_t offset);
 uint16_t bnx2x_reg_read16(struct bnx2x_softc *sc, size_t offset);
 uint32_t bnx2x_reg_read32(struct bnx2x_softc *sc, size_t offset);
diff --git a/drivers/net/bnx2x/bnx2x_logs.h b/drivers/net/bnx2x/bnx2x_logs.h
index d31c253..7ef6e64 100644
--- a/drivers/net/bnx2x/bnx2x_logs.h
+++ b/drivers/net/bnx2x/bnx2x_logs.h
@@ -47,4 +47,12 @@
 #define PMD_DRV_LOG(level, fmt, args...) \
PMD_DRV_LOG_RAW(level, fmt "\n", ## args)

+#ifdef RTE_LIBRTE_BNX2X_REG_ACCESS
+#define PMD_REG_ACCESS_LOG(level, fmt, args...) \
+   RTE_LOG(level, PMD, "%s(): " fmt "\n", __func__, ## args)
+#else
+#define PMD_REG_ACCESS_LOG(level, fmt, args...) do { } while(0)
+#endif
+
+
 #endif /* _PMD_LOGS_H_ */
diff --git a/drivers/net/bnx2x/debug.c b/drivers/net/bnx2x/debug.c
index 9ab4f1d..b5e29f7 100644
--- a/drivers/net/bnx2x/debug.c
+++ b/drivers/net/bnx2x/debug.c
@@ -44,7 +44,7 @@
 void
 bnx2x_reg_write8(struct bnx2x_softc *sc, size_t offset, uint8_t val)
 {
-   PMD_DRV_LOG(DEBUG, "offset=0x%08lx val=0x%02x", offset, val);
+   PMD_REG_ACCESS_LOG(DEBUG, "offset=0x%08lx val=0x%02x", offset, val);
*((volatile uint8_t*)((uint64_t)sc->bar[BAR0].base_addr + offset)) = 
val;
 }

@@ -52,10 +52,11 @@ void
 bnx2x_reg_write16(struct bnx2x_softc *sc, size_t offset, uint16_t val)
 {
if ((offset % 2) != 0) {
-   PMD_DRV_LOG(DEBUG, "Unaligned 16-bit write to 0x%08lx", offset);
+   PMD_DRV_LOG(NOTICE, "Unaligned 16-bit write to 0x%08lx",
+   offset);
}

-   PMD_DRV_LOG(DEBUG, "offset=0x%08lx val=0x%04x", offset, val);
+   PMD_REG_ACCESS_LOG(DEBUG, "offset=0x%08lx val=0x%04x", offset, val);
*((volatile uint16_t*)((uint64_t)sc->bar[BAR0].base_addr + offset)) = 
val;
 }

@@ -63,10 +64,11 @@ void
 bnx2x_reg_write32(struct bnx2x_softc *sc, size_t offset, uint32_t val)
 {
if ((offset % 4) != 0) {
-   PMD_DRV_LOG(DEBUG, "Unaligned 32-bit write to 0x%08lx", offset);
+   PMD_DRV_LOG(NOTICE, "Unaligned 32-bit write to 0x%08lx",
+   offset);
}

-   PMD_DRV_LOG(DEBUG, "offset=0x%08lx val=0x%08x", offset, val);
+   PMD_REG_ACCESS_LOG(DEBUG, "offset=0x%08lx val=0x%08x", offset, val);
*((volatile uint32_t*)((uint64_t)sc->bar[BAR0].base_addr + offset)) = 
val;
 }

@@ -76,7 +78,7 @@ bnx2x_reg_read8(struct bnx2x_softc *sc, size_t offset)
uint8_t val;

val = (uint8_t)(*((volatile uint8_t*)((uint64_t)sc->bar[BAR0].base_addr 
+ offset)));
-   PMD_DRV_LOG(DEBUG, "offset=0x%08lx val=0x%02x", offset, val);
+   PMD_REG_ACCESS_LOG(DEBUG, "offset=0x%08lx val=0x%02x", offset, val);

return (val);
 }
@@ -87,11 +89,12 @@ bnx2x_reg_read16(struct bnx2x_softc *sc, size_t offset)
uint16_t val;

if ((offset % 2) != 0) {
-   PMD_DRV_LOG(DEBUG, "Unaligned 16-bit read from 0x%08lx", 
offset);
+   PMD_DRV_LOG(NOTICE, "Unaligned 16-bit read from 0x%08lx",
+   offset);
}

val = (uint16_t)(*((volatile 
uint16_t*)((uint64_t)sc->bar[BAR0].base_addr + offset)));
-   PMD_DRV_LOG(DEBUG, "offset=0x%08lx val=0x%08x", offset, val);
+   

[dpdk-dev] [PATCH 2/5] bnx2x: Fix x86_64-native-linuxapp-clang build error

[Rasesh Mody]

From: Harish Patil 

Signed-off-by: Harish Patil 
---
 drivers/net/bnx2x/ecore_hsi.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/bnx2x/ecore_hsi.h b/drivers/net/bnx2x/ecore_hsi.h
index a4ed9b5..fe72938 100644
--- a/drivers/net/bnx2x/ecore_hsi.h
+++ b/drivers/net/bnx2x/ecore_hsi.h
@@ -2529,7 +2529,7 @@ struct shmem2_region {
#define SHMEM_EEE_SUPPORTED_SHIFT  16
#define SHMEM_EEE_ADV_STATUS_MASK  0x00f0
#define SHMEM_EEE_100M_ADV (1<<0)
-   #define SHMEM_EEE_1G_ADV   (1<<1)
+   #define SHMEM_EEE_1G_ADV   (1U<<1)
#define SHMEM_EEE_10G_ADV  (1<<2)
#define SHMEM_EEE_ADV_STATUS_SHIFT 20
#define SHMEM_EEE_LP_ADV_STATUS_MASK   0x0f00
-- 
1.7.10.3

[dpdk-dev] [PATCH 1/5] bnx2x: SR-IOV VF driver changes to support OOB PF driver

[Rasesh Mody]

From: Harish Patil 

Signed-off-by: Harish Patil 
---
 drivers/net/bnx2x/bnx2x_vfpf.c |   11 +--
 drivers/net/bnx2x/bnx2x_vfpf.h |   15 +++
 2 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/drivers/net/bnx2x/bnx2x_vfpf.c b/drivers/net/bnx2x/bnx2x_vfpf.c
index 661f0a5..39fd59a 100644
--- a/drivers/net/bnx2x/bnx2x_vfpf.c
+++ b/drivers/net/bnx2x/bnx2x_vfpf.c
@@ -257,8 +257,15 @@ int bnx2x_vf_get_resources(struct bnx2x_softc *sc, uint8_t 
tx_count, uint8_t rx_

acq->bulletin_addr = sc->pf2vf_bulletin_mapping.paddr;

-   BNX2X_TLV_APPEND(acq, acq->first_tlv.length, BNX2X_VF_TLV_LIST_END,
-   sizeof(struct channel_list_end_tlv));
+   /* Request physical port identifier */
+   BNX2X_TLV_APPEND(acq, acq->first_tlv.length,
+BNX2X_VF_TLV_PHYS_PORT_ID,
+sizeof(struct channel_tlv));
+
+   BNX2X_TLV_APPEND(acq,
+(acq->first_tlv.length + sizeof(struct channel_tlv)),
+BNX2X_VF_TLV_LIST_END,
+sizeof(struct channel_list_end_tlv));

/* requesting the resources in loop */
obtain_status = bnx2x_loop_obtain_resources(sc);
diff --git a/drivers/net/bnx2x/bnx2x_vfpf.h b/drivers/net/bnx2x/bnx2x_vfpf.h
index 94ce9f0..4f25321 100644
--- a/drivers/net/bnx2x/bnx2x_vfpf.h
+++ b/drivers/net/bnx2x/bnx2x_vfpf.h
@@ -34,12 +34,24 @@ struct vf_resource_query {
 #defineBNX2X_VF_Q_FLAG_DHC 0x0200
 #defineBNX2X_VF_Q_FLAG_LEADING_RSS 0x0400

+#define TLV_BUFFER_SIZE1024
+
+/* general tlv header (used for both vf->pf request and pf->vf response) */
+struct channel_tlv {
+   uint16_t type;
+   uint16_t length;
+};
+
 struct vf_first_tlv {
uint16_t type;
uint16_t length;
uint32_t reply_offset;
 };

+struct tlv_buffer_size {
+   uint8_t tlv_buffer[TLV_BUFFER_SIZE];
+};
+
 /* tlv struct for all PF replies except acquire */
 struct vf_common_reply_tlv {
uint16_t type;
@@ -244,12 +256,14 @@ union query_tlvs {
struct vf_release_tlv   release;
struct vf_rss_tlv   update_rss;
struct channel_list_end_tlv list_end;
+   struct tlv_buffer_size  tlv_buf_size;
 };

 union resp_tlvs {
struct vf_common_reply_tlv  common_reply;
struct vf_acquire_resp_tlv  acquire_resp;
struct channel_list_end_tlv list_end;
+   struct tlv_buffer_size  tlv_buf_size;
 };

 /* struct allocated by VF driver, PF sends updates to VF via bulletin */
@@ -300,6 +314,7 @@ enum channel_tlvs {
BNX2X_VF_TLV_PF_SET_MAC,
BNX2X_VF_TLV_PF_SET_VLAN,
BNX2X_VF_TLV_UPDATE_RSS,
+   BNX2X_VF_TLV_PHYS_PORT_ID,
BNX2X_VF_TLV_MAX
 };

-- 
1.7.10.3

[dpdk-dev] [PATCH 0/5] bnx2x: Enhancement, fixes, licensing and doumentation

[Rasesh Mody]

Hi

This patch set consists of enhancements, fixes, licensing and
documentation changes for the QLogic bnx2x Poll Mode Driver. The patches
have been generated and tested against latest dpdk tree.

Please apply.

Thanks!
Rasesh

Harish Patil (4):
  bnx2x: SR-IOV VF driver changes to support OOB PF driver
  bnx2x: Fix x86_64-native-linuxapp-clang build error
  bnx2x: Add RTE_LIBRTE_BNX2X_REG_ACCESS config option
  doc: Add BNX2X PMD documentation

Rasesh Mody (1):
  bnx2x: Add LICENSE.bnx2x_pmd and update source files

 config/common_linuxapp  |1 +
 doc/guides/nics/bnx2x.rst   |  324 +++
 drivers/net/bnx2x/LICENSE.bnx2x_pmd |   28 +++
 drivers/net/bnx2x/Makefile  |2 +-
 drivers/net/bnx2x/bnx2x.c   |   29 +---
 drivers/net/bnx2x/bnx2x.h   |   31 +---
 drivers/net/bnx2x/bnx2x_ethdev.c|4 +
 drivers/net/bnx2x/bnx2x_ethdev.h|4 +
 drivers/net/bnx2x/bnx2x_logs.h  |   12 ++
 drivers/net/bnx2x/bnx2x_rxtx.c  |4 +
 drivers/net/bnx2x/bnx2x_rxtx.h  |4 +
 drivers/net/bnx2x/bnx2x_stats.c |   27 +--
 drivers/net/bnx2x/bnx2x_stats.h |   27 +--
 drivers/net/bnx2x/bnx2x_vfpf.c  |   15 +-
 drivers/net/bnx2x/bnx2x_vfpf.h  |   19 ++
 drivers/net/bnx2x/debug.c   |   51 ++
 drivers/net/bnx2x/ecore_fw_defs.h   |   27 +--
 drivers/net/bnx2x/ecore_hsi.h   |   29 +---
 drivers/net/bnx2x/ecore_init.h  |   27 +--
 drivers/net/bnx2x/ecore_init_ops.h  |   27 +--
 drivers/net/bnx2x/ecore_mfw_req.h   |   27 +--
 drivers/net/bnx2x/ecore_reg.h   |   27 +--
 drivers/net/bnx2x/ecore_sp.c|   27 +--
 drivers/net/bnx2x/ecore_sp.h|   27 +--
 drivers/net/bnx2x/elink.c   |   29 +---
 drivers/net/bnx2x/elink.h   |   29 +---
 26 files changed, 483 insertions(+), 375 deletions(-)
 create mode 100644 doc/guides/nics/bnx2x.rst
 create mode 100644 drivers/net/bnx2x/LICENSE.bnx2x_pmd

-- 
1.7.10.3

[dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1 for all NICs but 82598

[Ananyev, Konstantin]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Matthew Hall
> Sent: Friday, September 11, 2015 6:18 PM
> To: Vladislav Zolotarov
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1 for 
> all NICs but 82598
> 
> On Fri, Sep 11, 2015 at 07:18:20PM +0300, Vladislav Zolotarov wrote:
> > We thought about linearization too. It's doable with extra mempool and it
> > may be optional so that those that don't need could compile it out and/or
> > disable it in a runtime...
> 
> High-level question. How realistic is sending a 40-segment frame in the first
> place? This whole thing seems kind of academic to me unless I missed
> something.
> 
> I usually use 2K pktmbufs and I don't think this is an uncommon size. Most
> jumbo frame hardware only does 9.5KB max frame size or so.
> 
> So I am having a hard time imagining how I'd end up with more than 10 segments
> as a worst-case scenario.

As I remember, with freebsd stack when TSO is on it was not unusual to see 
chains of ~30 segments. 
That's over port with 'normal' mtu (1.5K).
Konstantin

> 
> Matthew.

[dpdk-dev] [PATCH 1/2] rte_sched: whitespace cleanup

[Dumitrescu, Cristian]

> -Original Message-
> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> Sent: Friday, August 28, 2015 7:50 PM
> To: Dumitrescu, Cristian
> Cc: dev at dpdk.org; Stephen Hemminger
> Subject: [PATCH 1/2] rte_sched: whitespace cleanup
> 
> Break long lines, remove {} on single line conditionals, fix indentation,
> and break needlessly long lines.
> 
> Signed-off-by: Stephen Hemminger 
> ---
>  lib/librte_sched/rte_sched.c | 363 ++
> -
>  1 file changed, 182 insertions(+), 181 deletions(-)
> 
> diff --git a/lib/librte_sched/rte_sched.c b/lib/librte_sched/rte_sched.c
> index 9c9419d..924c172 100644
> --- a/lib/librte_sched/rte_sched.c
> +++ b/lib/librte_sched/rte_sched.c
> @@ -317,88 +317,74 @@ rte_sched_port_check_params(struct
> rte_sched_port_params *params)
>  {
>   uint32_t i, j;
> 
> - if (params == NULL) {
> + if (params == NULL)
>   return -1;
> - }
> 
>   /* socket */
> - if ((params->socket < 0) || (params->socket >=
> RTE_MAX_NUMA_NODES)) {
> + if ((params->socket < 0) || (params->socket >=
> RTE_MAX_NUMA_NODES))
>   return -3;
> - }
> 
>   /* rate */
> - if (params->rate == 0) {
> + if (params->rate == 0)
>   return -4;
> - }
> 
>   /* mtu */
> - if (params->mtu == 0) {
> + if (params->mtu == 0)
>   return -5;
> - }
> 
>   /* n_subports_per_port: non-zero, power of 2 */
> - if ((params->n_subports_per_port == 0) ||
> (!rte_is_power_of_2(params->n_subports_per_port))) {
> + if ((params->n_subports_per_port == 0) ||
> (!rte_is_power_of_2(params->n_subports_per_port)))
>   return -6;
> - }
> 
>   /* n_pipes_per_subport: non-zero, power of 2 */
> - if ((params->n_pipes_per_subport == 0) ||
> (!rte_is_power_of_2(params->n_pipes_per_subport))) {
> + if ((params->n_pipes_per_subport == 0) ||
> (!rte_is_power_of_2(params->n_pipes_per_subport)))
>   return -7;
> - }
> 
>   /* qsize: non-zero, power of 2, no bigger than 32K (due to 16-bit
> read/write pointers) */
> - for (i = 0; i < RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE; i ++) {
> + for (i = 0; i < RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE; i++) {
>   uint16_t qsize = params->qsize[i];
> 
> - if ((qsize == 0) || (!rte_is_power_of_2(qsize))) {
> + if ((qsize == 0) || (!rte_is_power_of_2(qsize)))
>   return -8;
> - }
>   }
> 
>   /* pipe_profiles and n_pipe_profiles */
>   if ((params->pipe_profiles == NULL) ||
>   (params->n_pipe_profiles == 0) ||
> - (params->n_pipe_profiles >
> RTE_SCHED_PIPE_PROFILES_PER_PORT)) {
> + (params->n_pipe_profiles >
> RTE_SCHED_PIPE_PROFILES_PER_PORT))
>   return -9;
> - }
> 
> - for (i = 0; i < params->n_pipe_profiles; i ++) {
> + for (i = 0; i < params->n_pipe_profiles; i++) {
>   struct rte_sched_pipe_params *p = params->pipe_profiles +
> i;
> 
>   /* TB rate: non-zero, not greater than port rate */
> - if ((p->tb_rate == 0) || (p->tb_rate > params->rate)) {
> + if ((p->tb_rate == 0) || (p->tb_rate > params->rate))
>   return -10;
> - }
> 
>   /* TB size: non-zero */
> - if (p->tb_size == 0) {
> + if (p->tb_size == 0)
>   return -11;
> - }
> 
>   /* TC rate: non-zero, less than pipe rate */
> - for (j = 0; j < RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE; j ++) {
> - if ((p->tc_rate[j] == 0) || (p->tc_rate[j] > p-
> >tb_rate)) {
> + for (j = 0; j < RTE_SCHED_TRAFFIC_CLASSES_PER_PIPE; j++) {
> + if ((p->tc_rate[j] == 0) || (p->tc_rate[j] > p-
> >tb_rate))
>   return -12;
> - }
>   }
> 
>   /* TC period: non-zero */
> - if (p->tc_period == 0) {
> + if (p->tc_period == 0)
>   return -13;
> - }
> 
>  #ifdef RTE_SCHED_SUBPORT_TC_OV
>   /* TC3 oversubscription weight: non-zero */
> - if (p->tc_ov_weight == 0) {
> + if (p->tc_ov_weight == 0)
>   return -14;
> - }
>  #endif
> 
>   /* Queue WRR weights: non-zero */
> - for (j = 0; j < RTE_SCHED_QUEUES_PER_PIPE; j ++) {
> - if (p->wrr_weights[j] == 0) {
> + for (j = 0; j < RTE_SCHED_QUEUES_PER_PIPE; j++) {
> + if (p->wrr_weights[j] == 0)
>   return -15;
> - }
>   }
>   }
> 
> @@ -424,34 +410,42 @@ rte_sched_port_get_array_base(struct
> rte_sched_port_params *params, enum rte_sch
>   uint32_t base, i;
> 
>   size_per_pipe_queue_array = 0;
> - for (i = 0; i < 

[dpdk-dev] [PATCH 2/2] rte_sched: remove useless bitmap_free

[Dumitrescu, Cristian]

> -Original Message-
> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> Sent: Friday, August 28, 2015 7:50 PM
> To: Dumitrescu, Cristian
> Cc: dev at dpdk.org; Stephen Hemminger
> Subject: [PATCH 2/2] rte_sched: remove useless bitmap_free
> 
> Coverity reports that rte_bitmap_free() does nothing and caller does
> not check return value. Just remove it.
> 
> Also since rte_free(NULL) is a nop, remove useless check here.
> 
> Signed-off-by: Stephen Hemminger 
> ---
>  lib/librte_sched/rte_bitmap.h | 19 ---
>  lib/librte_sched/rte_sched.c  |  5 -
>  2 files changed, 24 deletions(-)
> 
> diff --git a/lib/librte_sched/rte_bitmap.h b/lib/librte_sched/rte_bitmap.h
> index 216a344..47b 100644
> --- a/lib/librte_sched/rte_bitmap.h
> +++ b/lib/librte_sched/rte_bitmap.h
> @@ -275,25 +275,6 @@ rte_bitmap_init(uint32_t n_bits, uint8_t *mem,
> uint32_t mem_size)
>  }
> 
>  /**
> - * Bitmap free
> - *
> - * @param bmp
> - *   Handle to bitmap instance
> - * @return
> - *   0 upon success, error code otherwise
> - */
> -static inline int
> -rte_bitmap_free(struct rte_bitmap *bmp)
> -{
> - /* Check input arguments */
> - if (bmp == NULL) {
> - return -1;
> - }
> -
> - return 0;
> -}
> -
> -/**
>   * Bitmap reset
>   *
>   * @param bmp
> diff --git a/lib/librte_sched/rte_sched.c b/lib/librte_sched/rte_sched.c
> index 924c172..cbe3f3b 100644
> --- a/lib/librte_sched/rte_sched.c
> +++ b/lib/librte_sched/rte_sched.c
> @@ -716,11 +716,6 @@ rte_sched_port_config(struct
> rte_sched_port_params *params)
>  void
>  rte_sched_port_free(struct rte_sched_port *port)
>  {
> - /* Check user parameters */
> - if (port == NULL)
> - return;
> -
> - rte_bitmap_free(port->bmp);
>   rte_free(port);
>  }
> 
> --
> 2.1.4

Hi Steve,

I agree these functions are not doing much at the moment, but I would like to 
keep them for the reasons below:

1. There might be people using them, and we do not want to break their code. 
Removing them is an ABI change.

2. Although they are just placeholders for now, we might need to add more 
functionality to them going forward, as the implementation evolves. I don't 
want to change the API now by removing them, and change the API later when we 
need to add them back. Generally, I think it is good practice to have free 
functions.

Regards,
Cristian

[dpdk-dev] [PATCH v4] ixgbe_pmd: enforce RS bit on every EOP descriptor for devices newer than 82598

[Konstantin Ananyev]

Hi Vlad,

>> Unfortunately we are seeing a huge performance drop with that patch:
>> On my box bi-directional traffic (64B packet) over one port can't reach even 
>> 11 Mpps.
>Konstantin, could u clarify - u saw "only" 11 Mpps with v3 of this patch which 
>doesn't change the rs_thresh and only sets RS on every packet? What is the 
>performance in the same test without this patch? 

Yes, that's with you latest patch - v4.
I am seeing:
vectorRX+fullfeaturedTX over 1 port:
orig_code   14.74 Mpps
your_patch: 10.6 Mpps

Actually, while we speaking about it,
could you try another patch for that issue on your test environment,
see below.
It seems to fix the problem in our test environment.
It is based on the observation that it is ok not to set RS on each EOP if:
the distance between TDs with RS bit set doesn't exceed size of
on-die descriptor queue (40 descriptors).

With that approach I also see a slight performance drop
but it is much less then with your approach:
with the same conditions it can do 14.2 Mpps over 1 port.

Thanks
Konstantin


Signed-off-by: Konstantin Ananyev 
---
 drivers/net/ixgbe/ixgbe_rxtx.c | 25 +++--
 1 file changed, 19 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
index 91023b9..a7a32ad 100644
--- a/drivers/net/ixgbe/ixgbe_rxtx.c
+++ b/drivers/net/ixgbe/ixgbe_rxtx.c
@@ -573,7 +573,7 @@ ixgbe_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
struct ixgbe_tx_entry *sw_ring;
struct ixgbe_tx_entry *txe, *txn;
volatile union ixgbe_adv_tx_desc *txr;
-   volatile union ixgbe_adv_tx_desc *txd;
+   volatile union ixgbe_adv_tx_desc *txd, *txp;
struct rte_mbuf *tx_pkt;
struct rte_mbuf *m_seg;
uint64_t buf_dma_addr;
@@ -596,6 +596,7 @@ ixgbe_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
txr = txq->tx_ring;
tx_id   = txq->tx_tail;
txe = _ring[tx_id];
+   txp = NULL;

/* Determine if the descriptor ring needs to be cleaned. */
if (txq->nb_tx_free < txq->tx_free_thresh)
@@ -639,6 +640,12 @@ ixgbe_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
 */
nb_used = (uint16_t)(tx_pkt->nb_segs + new_ctx);

+   if (txp != NULL &&
+   nb_used + txq->nb_tx_used >= txq->tx_rs_thresh)
+   /* set RS on the previous packet in the burst */
+   txp->read.cmd_type_len |=
+   rte_cpu_to_le_32(IXGBE_TXD_CMD_RS);
+
/*
 * The number of descriptors that must be allocated for a
 * packet is the number of segments of that packet, plus 1
@@ -843,8 +850,14 @@ ixgbe_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
txq->nb_tx_used = 0;
}
txd->read.cmd_type_len |= rte_cpu_to_le_32(cmd_type_len);
+   txp = txd;
}
+
 end_of_tx:
+   /* set RS on last packet in the burst */
+   if (txp != NULL)
+   txp->read.cmd_type_len |= rte_cpu_to_le_32(IXGBE_TXD_CMD_RS);
+   
rte_wmb();

/*
@@ -2124,11 +2137,11 @@ ixgbe_dev_tx_queue_setup(struct rte_eth_dev *dev,
tx_conf->tx_rs_thresh : DEFAULT_TX_RS_THRESH);
tx_free_thresh = (uint16_t)((tx_conf->tx_free_thresh) ?
tx_conf->tx_free_thresh : DEFAULT_TX_FREE_THRESH);
-   if (tx_rs_thresh >= (nb_desc - 2)) {
-   PMD_INIT_LOG(ERR, "tx_rs_thresh must be less than the number "
-"of TX descriptors minus 2. (tx_rs_thresh=%u "
-"port=%d queue=%d)", (unsigned int)tx_rs_thresh,
-(int)dev->data->port_id, (int)queue_idx);
+   if (tx_rs_thresh > DEFAULT_TX_RS_THRESH) {
+   PMD_INIT_LOG(ERR, "tx_rs_thresh must be less than %u. "
+   "(tx_rs_thresh=%u port=%d queue=%d)",
+   DEFAULT_TX_FREE_THRESH, (unsigned int)tx_rs_thresh,
+   (int)dev->data->port_id, (int)queue_idx);
return -(EINVAL);
}
if (tx_free_thresh >= (nb_desc - 3)) {
-- 
1.8.3.1

[dpdk-dev] Compiling MLX4 Support into 2.1.0

[Olga Shern]

Nathan,

What application are you running?
Please send the output of it.
Please send output of ofed_info  -s, ibdev2netdev and ibv_devinfo. Do you see 
any errors in dmesg?

Regards,
Olga


Sent from Samsung Mobile.


 Original message 
From: Nathan Speulda
Date:11/09/2015 7:51 PM (GMT+02:00)
To: Nathan Speulda ,dev at dpdk.org
Subject: Re: [dpdk-dev] Compiling MLX4 Support into 2.1.0

Thank you for the response,

I followed all of the documentation before I came to the forum on this
one.  OFED is installed and working correctly with all drivers loaded.  I
get to the point of compiling dpdk with support enabled and nothing appears
to come out during the compile (for mlx4 which is included in the
.config).  My interfaces are not being seen by the PMD though I am aware it
works differently than the base supported adapters.

Thanks,
Nathan

On Fri, Sep 11, 2015 at 9:35 AM, Adrien Mazarguil <
adrien.mazarguil at 6wind.com> wrote:

> Hi Nathan,
>
> On Fri, Sep 11, 2015 at 09:10:03AM -0700, Nathan Speulda wrote:
> > All,
> >
> > I am attempting to do some work using a CX3-Pro adapter in a forwarding
> > environment and am attempting to enable the supported PMD that is
> included
> > in the 2.1.0 release of DPDK.  My base distro is RHEL6.5 for stability
> > reasons.  Does anyone have a more detailed idea of how to get the
> Mellanox
> > PMD working correctly?  Does base distro have any impact on this at
> all?  I
> > have been unable to find what I need at the Mellanox community support.
>
> You need to install Mellanox OFED before attempting to compile the mlx4
> PMD, as described in the relevant documentation (doc/guides/nics/mlx4.rst)
> also available here:
>
>  http://dpdk.org/doc/guides/nics/mlx4.html
>
> See "Prerequisites" and "Getting Mellanox OFED" sections.
>
> It should work fine with all Linux distributions supported by Mellanox
> OFED. In your specific case, RHEL 6.5 is supported by MOFED 3.0-2.0.1.
>
> --
> Adrien Mazarguil
> 6WIND
>

[dpdk-dev] rte_eal_init() alternative?

[Wiles, Keith]

On 9/8/15, 1:01 PM, "Don Provan"  wrote:

>From: Wiles, Keith:
>>That stated I am not a big fan of huge structures being passed into
>>a init routine as that structure would need to be versioned and it will
>>grow/change. Plus he did not really want to deal in strings, so the
>>structure would be binary values and strings as required.
>
>A typical library has an init routine which establishes defaults, and
>then the application adjusts parameters through targeted set routines
>before starting to use the library operationally. In the argc/argv
>wrapper, the parsing code would call one of those individual routines
>when it parses the corresponding command line flag.
>
>The idea that there has to be one massive init routine which is
>passed every possible configuration parameter is more of the same
>monolithic thinking that DPDK needs to shake.

I am not sure DPDK has a lot of monolithic parts, so I do not fully
understand your statement, if you mean we should carefully add this
support in the correct way then I agree.

Some items may need to be passed into the first routine and other items
can be set via the setter routines. The problem is the current routine
does it all at once and it will need go be broken down to do as you say
with setter routines. Passing in a few options or a small structure can
still work, but we should not try to create a huge structure.

Today we have one API rte_eal_init() and breaking this up into 20 routines
is going to be a problem IMO, we need to strike a balance of some type
that does not use argc/argv or we add new APIs.
>
>-don provan
>dprovan at bivio.net
>


? 
Regards,
++Keith
Intel Corporation

[dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1 for all NICs but 82598

[didier.pallard]

On 08/25/2015 08:52 PM, Vlad Zolotarov wrote:
>
> Helin, the issue has been seen on x540 devices. Pls., see a chapter 
> 7.2.1.1 of x540 devices spec:
>
> A packet (or multiple packets in transmit segmentation) can span any 
> number of
> buffers (and their descriptors) up to a limit of 40 minus WTHRESH 
> minus 2 (see
> Section 7.2.3.3 for Tx Ring details and section Section 7.2.3.5.1 for 
> WTHRESH
> details). For best performance it is recommended to minimize the 
> number of buffers
> as possible.
>
> Could u, pls., clarify why do u think that the maximum number of data 
> buffers is limited by 8?
>
> thanks,
> vlad

Hi vlad,

Documentation states that a packet (or multiple packets in transmit 
segmentation) can span any number of
buffers (and their descriptors) up to a limit of 40 minus WTHRESH minus 2.

Shouldn't there be a test in transmit function that drops properly the 
mbufs with a too large number of
segments, while incrementing a statistic; otherwise transmit function 
may be locked by the faulty packet without
notification.

thanks
didier

[dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1 for all NICs but 82598

[Richardson, Bruce]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Vladislav Zolotarov
> Sent: Friday, September 11, 2015 5:04 PM
> To: Avi Kivity
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1
> for all NICs but 82598
> 
> On Sep 11, 2015 6:43 PM, "Avi Kivity"  wrote:
> >
> > On 09/11/2015 06:12 PM, Vladislav Zolotarov wrote:
> >>
> >>
> >> On Sep 11, 2015 5:55 PM, "Thomas Monjalon"
> >> 
> wrote:
> >> >
> >> > 2015-09-11 17:47, Avi Kivity:
> >> > > On 09/11/2015 05:25 PM, didier.pallard wrote:
> >> > > > On 08/25/2015 08:52 PM, Vlad Zolotarov wrote:
> >> > > >>
> >> > > >> Helin, the issue has been seen on x540 devices. Pls., see a
> chapter
> >> > > >> 7.2.1.1 of x540 devices spec:
> >> > > >>
> >> > > >> A packet (or multiple packets in transmit segmentation) can
> >> > > >> span
> any
> >> > > >> number of
> >> > > >> buffers (and their descriptors) up to a limit of 40 minus
> >> > > >> WTHRESH minus 2 (see Section 7.2.3.3 for Tx Ring details and
> >> > > >> section Section 7.2.3.5.1
> for
> >> > > >> WTHRESH
> >> > > >> details). For best performance it is recommended to minimize
> >> > > >> the number of buffers as possible.
> >> > > >>
> >> > > >> Could u, pls., clarify why do u think that the maximum number
> >> > > >> of
> data
> >> > > >> buffers is limited by 8?
> >> > > >>
> >> > > >> thanks,
> >> > > >> vlad
> >> > > >
> >> > > > Hi vlad,
> >> > > >
> >> > > > Documentation states that a packet (or multiple packets in
> >> > > > transmit
> >> > > > segmentation) can span any number of buffers (and their
> >> > > > descriptors) up to a limit of 40 minus WTHRESH minus 2.
> >> > > >
> >> > > > Shouldn't there be a test in transmit function that drops
> >> > > > properly
> the
> >> > > > mbufs with a too large number of segments, while incrementing a
> >> > > > statistic; otherwise transmit
> function
> >> > > > may be locked by the faulty packet without notification.
> >> > > >
> >> > >
> >> > > What we proposed is that the pmd expose to dpdk, and dpdk expose
> >> > > to
> the
> >> > > application, an mbuf check function.  This way applications that
> >> > > can generate complex packets can verify that the device will be
> >> > > able to process them, and applications that only generate simple
> >> > > mbufs can
> avoid
> >> > > the overhead by not calling the function.
> >> >
> >> > More than a check, it should be exposed as a capability of the port.
> >> > Anyway, if the application sends too much segments, the driver must
> >> > drop it to avoid hang, and maintain a dedicated statistic counter
> >> > to
> allow
> >> > easy debugging.
> >>
> >> I agree with Thomas - this should not be optional. Malformed packets
> should be dropped. In the icgbe case it's a very simple test - it's a
> single branch per packet so i doubt that it could impose any measurable
> performance degradation.
> >>
> >>
> >
> > A drop allows the application no chance to recover.  The driver must
> either provide the ability for the application to know that it cannot
> accept the packet, or it must fix it up itself.
> 
> An appropriate statistics counter would be a perfect tool to detect such
> issues. Knowingly sending a packet that will cause a HW to hang is not
> acceptable.

I would agree. Drivers should provide a function to query the max number of
segments they can accept and the driver should be able to discard any packets
exceeding that number, and just track it via a stat.

/Bruce

[dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1 for all NICs but 82598

[Richardson, Bruce]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Vladislav Zolotarov
> Sent: Friday, September 11, 2015 4:13 PM
> To: Thomas Monjalon
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1
> for all NICs but 82598
> 
> On Sep 11, 2015 5:55 PM, "Thomas Monjalon" 
> wrote:
> >
> > 2015-09-11 17:47, Avi Kivity:
> > > On 09/11/2015 05:25 PM, didier.pallard wrote:
> > > > On 08/25/2015 08:52 PM, Vlad Zolotarov wrote:
> > > >>
> > > >> Helin, the issue has been seen on x540 devices. Pls., see a
> > > >> chapter
> > > >> 7.2.1.1 of x540 devices spec:
> > > >>
> > > >> A packet (or multiple packets in transmit segmentation) can span
> > > >> any number of buffers (and their descriptors) up to a limit of 40
> > > >> minus WTHRESH minus 2 (see Section 7.2.3.3 for Tx Ring details
> > > >> and section Section 7.2.3.5.1 for WTHRESH details). For best
> > > >> performance it is recommended to minimize the number of buffers
> > > >> as possible.
> > > >>
> > > >> Could u, pls., clarify why do u think that the maximum number of
> > > >> data buffers is limited by 8?
> > > >>
> > > >> thanks,
> > > >> vlad
> > > >
> > > > Hi vlad,
> > > >
> > > > Documentation states that a packet (or multiple packets in
> > > > transmit
> > > > segmentation) can span any number of buffers (and their
> > > > descriptors) up to a limit of 40 minus WTHRESH minus 2.
> > > >
> > > > Shouldn't there be a test in transmit function that drops properly
> > > > the mbufs with a too large number of segments, while incrementing
> > > > a statistic; otherwise transmit function may be locked by the
> > > > faulty packet without notification.
> > > >
> > >
> > > What we proposed is that the pmd expose to dpdk, and dpdk expose to
> > > the application, an mbuf check function.  This way applications that
> > > can generate complex packets can verify that the device will be able
> > > to process them, and applications that only generate simple mbufs
> > > can avoid the overhead by not calling the function.
> >
> > More than a check, it should be exposed as a capability of the port.
> > Anyway, if the application sends too much segments, the driver must
> > drop it to avoid hang, and maintain a dedicated statistic counter to
> > allow easy debugging.
> 
> I agree with Thomas - this should not be optional. Malformed packets
> should be dropped. In the icgbe case it's a very simple test - it's a
> single branch per packet so i doubt that it could impose any measurable
> performance degradation.
> 
Actually, it could very well do - we'd have to test it. For the vector IO
paths, every additional cycle in the RX or TX paths causes a noticeable perf
drop.

/Bruce

[dpdk-dev] [PATCH 4/4] librte_port: modify release notes and deprecation notice

[roy.fan.zh...@intel.com]

From: Fan Zhang 

The LIBABIVER number is incremented. The release notes
is updated and the deprecation announce is removed.

Signed-off-by: Fan Zhang 
---
 doc/guides/rel_notes/deprecation.rst | 5 -
 doc/guides/rel_notes/release_2_2.rst | 4 +++-
 lib/librte_port/Makefile | 2 +-
 3 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index fffad80..d08ba63 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -52,11 +52,6 @@ Deprecation Notices
   the value of macros CFG_NAME_LEN and CFG_NAME_VAL will be increased.
   Most likely, the new values will be 64 and 256, respectively.

-* librte_port: Macros to access the packet meta-data stored within the
-  packet buffer will be adjusted to cover the packet mbuf structure as well,
-  as currently they are able to access any packet buffer location except the
-  packet mbuf structure.
-
 * librte_table LPM: A new parameter to hold the table name will be added to
   the LPM table parameter structure.

diff --git a/doc/guides/rel_notes/release_2_2.rst 
b/doc/guides/rel_notes/release_2_2.rst
index 682f468..4d945db 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -47,6 +47,8 @@ ABI Changes

 * The LPM structure is changed. The deprecated field mem_location is removed.

+* librte_port: Macros to access the packet meta-data stored within the packet
+  buffer has been adjusted to cover the packet mbuf structure.

 Shared Library Versions
 ---
@@ -74,7 +76,7 @@ The libraries prepended with a plus sign were incremented in 
this version.
  librte_pipeline.so.1
  librte_pmd_bond.so.1
+ librte_pmd_ring.so.2
- librte_port.so.1
+ librte_port.so.2
  librte_power.so.1
  librte_reorder.so.1
  librte_ring.so.1
diff --git a/lib/librte_port/Makefile b/lib/librte_port/Makefile
index ddbb383..410053e 100644
--- a/lib/librte_port/Makefile
+++ b/lib/librte_port/Makefile
@@ -41,7 +41,7 @@ CFLAGS += $(WERROR_FLAGS)

 EXPORT_MAP := rte_port_version.map

-LIBABIVER := 1
+LIBABIVER := 2

 #
 # all source are stored in SRCS-y
-- 
2.1.0

[dpdk-dev] [PATCH 3/4] app/test_pipeline: modify pipeline test

[roy.fan.zh...@intel.com]

From: Fan Zhang 

Test_pipeline has been modified to work on updated macros to access
meta-data stored in the mbuf structure.

Signed-off-by: Fan Zhang 
---
 app/test-pipeline/main.h  |  2 ++
 app/test-pipeline/pipeline_hash.c | 34 ++
 app/test-pipeline/pipeline_lpm.c  |  2 +-
 app/test-pipeline/pipeline_lpm_ipv6.c |  2 +-
 4 files changed, 22 insertions(+), 18 deletions(-)

diff --git a/app/test-pipeline/main.h b/app/test-pipeline/main.h
index 0c90fc3..8dcd459 100644
--- a/app/test-pipeline/main.h
+++ b/app/test-pipeline/main.h
@@ -137,4 +137,6 @@ void app_main_loop_tx(void);
 #define APP_FLUSH 0x3FF
 #endif

+#define APP_METADATA_OFFSET(offset) (sizeof(struct rte_mbuf) + (offset))
+
 #endif /* _MAIN_H_ */
diff --git a/app/test-pipeline/pipeline_hash.c 
b/app/test-pipeline/pipeline_hash.c
index 548615f..5e4e17f 100644
--- a/app/test-pipeline/pipeline_hash.c
+++ b/app/test-pipeline/pipeline_hash.c
@@ -163,8 +163,8 @@ app_main_loop_worker_pipeline_hash(void) {
.n_buckets_ext = 1 << 21,
.f_hash = test_hash,
.seed = 0,
-   .signature_offset = 0,
-   .key_offset = 32,
+   .signature_offset = APP_METADATA_OFFSET(0),
+   .key_offset = APP_METADATA_OFFSET(32),
};

struct rte_pipeline_table_params table_params = {
@@ -214,8 +214,8 @@ app_main_loop_worker_pipeline_hash(void) {
struct rte_table_hash_key8_ext_params table_hash_params = {
.n_entries = 1 << 24,
.n_entries_ext = 1 << 23,
-   .signature_offset = 0,
-   .key_offset = 32,
+   .signature_offset = APP_METADATA_OFFSET(0),
+   .key_offset = APP_METADATA_OFFSET(32),
.f_hash = test_hash,
.seed = 0,
};
@@ -238,8 +238,8 @@ app_main_loop_worker_pipeline_hash(void) {
{
struct rte_table_hash_key8_lru_params table_hash_params = {
.n_entries = 1 << 24,
-   .signature_offset = 0,
-   .key_offset = 32,
+   .signature_offset = APP_METADATA_OFFSET(0),
+   .key_offset = APP_METADATA_OFFSET(32),
.f_hash = test_hash,
.seed = 0,
};
@@ -263,8 +263,8 @@ app_main_loop_worker_pipeline_hash(void) {
struct rte_table_hash_key16_ext_params table_hash_params = {
.n_entries = 1 << 24,
.n_entries_ext = 1 << 23,
-   .signature_offset = 0,
-   .key_offset = 32,
+   .signature_offset = APP_METADATA_OFFSET(0),
+   .key_offset = APP_METADATA_OFFSET(32),
.f_hash = test_hash,
.seed = 0,
};
@@ -287,8 +287,8 @@ app_main_loop_worker_pipeline_hash(void) {
{
struct rte_table_hash_key16_lru_params table_hash_params = {
.n_entries = 1 << 24,
-   .signature_offset = 0,
-   .key_offset = 32,
+   .signature_offset = APP_METADATA_OFFSET(0),
+   .key_offset = APP_METADATA_OFFSET(32),
.f_hash = test_hash,
.seed = 0,
};
@@ -312,8 +312,8 @@ app_main_loop_worker_pipeline_hash(void) {
struct rte_table_hash_key32_ext_params table_hash_params = {
.n_entries = 1 << 24,
.n_entries_ext = 1 << 23,
-   .signature_offset = 0,
-   .key_offset = 32,
+   .signature_offset = APP_METADATA_OFFSET(0),
+   .key_offset = APP_METADATA_OFFSET(32),
.f_hash = test_hash,
.seed = 0,
};
@@ -337,8 +337,8 @@ app_main_loop_worker_pipeline_hash(void) {
{
struct rte_table_hash_key32_lru_params table_hash_params = {
.n_entries = 1 << 24,
-   .signature_offset = 0,
-   .key_offset = 32,
+   .signature_offset = APP_METADATA_OFFSET(0),
+   .key_offset = APP_METADATA_OFFSET(32),
.f_hash = test_hash,
.seed = 0,
};
@@ -456,8 +456,10 @@ app_main_loop_rx_metadata(void) {

m = app.mbuf_rx.array[j];
m_data = rte_pktmbuf_mtod(m, uint8_t *);
-   signature = RTE_MBUF_METADATA_UINT32_PTR(m, 0);
-   key = RTE_MBUF_METADATA_UINT8_PTR(m, 

[dpdk-dev] [PATCH 2/4] app/test: modify table and pipeline test

[roy.fan.zh...@intel.com]

From: Fan Zhang 

Test_table has been modified to work on updated macros to access meta-data
stored in the mbuf structure.

Signed-off-by: Fan Zhang 
---
 app/test/test_table.h  |  8 ++--
 app/test/test_table_combined.c | 28 +--
 app/test/test_table_pipeline.c |  3 ++-
 app/test/test_table_tables.c   | 44 ++
 4 files changed, 45 insertions(+), 38 deletions(-)

diff --git a/app/test/test_table.h b/app/test/test_table.h
index accc6f8..2077893 100644
--- a/app/test/test_table.h
+++ b/app/test/test_table.h
@@ -78,6 +78,8 @@
 #define MP_FLAGS0

 /* Macros */
+#define APP_METADATA_OFFSET(offset) (sizeof(struct rte_mbuf) + (offset))
+
 #define RING_ENQUEUE(ring, value) do { \
struct rte_mbuf *m; \
uint32_t *k32, *signature;  \
@@ -86,8 +88,10 @@
m = rte_pktmbuf_alloc(pool);\
if (m == NULL)  \
return -1;  \
-   signature = RTE_MBUF_METADATA_UINT32_PTR(m, 0); \
-   key = RTE_MBUF_METADATA_UINT8_PTR(m, 32);   \
+   signature = RTE_MBUF_METADATA_UINT32_PTR(m, \
+   APP_METADATA_OFFSET(0));\
+   key = RTE_MBUF_METADATA_UINT8_PTR(m,\
+   APP_METADATA_OFFSET(32));   \
k32 = (uint32_t *) key; \
k32[0] = (value);   \
*signature = pipeline_test_hash(key, 0, 0); \
diff --git a/app/test/test_table_combined.c b/app/test/test_table_combined.c
index dd09da5..5da005b 100644
--- a/app/test/test_table_combined.c
+++ b/app/test/test_table_combined.c
@@ -295,7 +295,7 @@ test_table_lpm_combined(void)
struct rte_table_lpm_params lpm_params = {
.n_rules = 1 << 16,
.entry_unique_size = 8,
-   .offset = 0,
+   .offset = APP_METADATA_OFFSET(0),
};

struct rte_table_lpm_key lpm_key = {
@@ -355,7 +355,7 @@ test_table_lpm_ipv6_combined(void)
.n_rules = 1 << 16,
.number_tbl8s = 1 << 13,
.entry_unique_size = 8,
-   .offset = 32,
+   .offset = APP_METADATA_OFFSET(32),
};

struct rte_table_lpm_ipv6_key lpm_ipv6_key = {
@@ -417,8 +417,8 @@ test_table_hash8lru(void)
.n_entries = 1<<24,
.f_hash = pipeline_test_hash,
.seed = 0,
-   .signature_offset = 0,
-   .key_offset = 32,
+   .signature_offset = APP_METADATA_OFFSET(0),
+   .key_offset = APP_METADATA_OFFSET(32),
};

uint8_t key8lru[8];
@@ -475,8 +475,8 @@ test_table_hash16lru(void)
.n_entries = 1<<16,
.f_hash = pipeline_test_hash,
.seed = 0,
-   .signature_offset = 0,
-   .key_offset = 32,
+   .signature_offset = APP_METADATA_OFFSET(0),
+   .key_offset = APP_METADATA_OFFSET(32),
};

uint8_t key16lru[16];
@@ -533,8 +533,8 @@ test_table_hash32lru(void)
.n_entries = 1<<16,
.f_hash = pipeline_test_hash,
.seed = 0,
-   .signature_offset = 0,
-   .key_offset = 32,
+   .signature_offset = APP_METADATA_OFFSET(0),
+   .key_offset = APP_METADATA_OFFSET(32),
};

uint8_t key32lru[32];
@@ -592,8 +592,8 @@ test_table_hash8ext(void)
.n_entries_ext = 1<<15,
.f_hash = pipeline_test_hash,
.seed = 0,
-   .signature_offset = 0,
-   .key_offset = 32,
+   .signature_offset = APP_METADATA_OFFSET(0),
+   .key_offset = APP_METADATA_OFFSET(32),
};

uint8_t key8ext[8];
@@ -658,8 +658,8 @@ test_table_hash16ext(void)
.n_entries_ext = 1<<15,
.f_hash = pipeline_test_hash,
.seed = 0,
-   .signature_offset = 0,
-   .key_offset = 32,
+   .signature_offset = APP_METADATA_OFFSET(0),
+   .key_offset = APP_METADATA_OFFSET(32),
};

uint8_t key16ext[16];
@@ -724,8 +724,8 @@ test_table_hash32ext(void)
.n_entries_ext = 1<<15,
.f_hash = pipeline_test_hash,
.seed = 0,
-   .signature_offset = 0,
-   .key_offset = 32,
+   .signature_offset = APP_METADATA_OFFSET(0),
+   .key_offset = APP_METADATA_OFFSET(32),
};

uint8_t key32ext[32];
diff 

[dpdk-dev] [PATCH 1/4] librte_port: modify macros to access packet meta-data

[roy.fan.zh...@intel.com]

From: Fan Zhang 

This patch relates to ABI change proposed for librte_port. Macros to
access the packet meta-data stored within the packet buffer has been
adjusted to cover the packet mbuf structure.

Signed-off-by: Fan Zhang 
---
 lib/librte_port/rte_port.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/librte_port/rte_port.h b/lib/librte_port/rte_port.h
index 396c7e9..00b97a9 100644
--- a/lib/librte_port/rte_port.h
+++ b/lib/librte_port/rte_port.h
@@ -55,7 +55,7 @@ extern "C" {
  * just beyond the end of the mbuf data structure returned by a port
  */
 #define RTE_MBUF_METADATA_UINT8_PTR(mbuf, offset)  \
-   (&((uint8_t *) &(mbuf)[1])[offset])
+   (&((uint8_t *)(mbuf))[offset])
 #define RTE_MBUF_METADATA_UINT16_PTR(mbuf, offset) \
((uint16_t *) RTE_MBUF_METADATA_UINT8_PTR(mbuf, offset))
 #define RTE_MBUF_METADATA_UINT32_PTR(mbuf, offset) \
-- 
2.1.0

[dpdk-dev] [PATCH 0/4]librte_port: modify macros to access packet meta-data

[roy.fan.zh...@intel.com]

From: Fan Zhang 

This patchset links to ABI change announced for librte_port. Macros to
access the packet meta-data stored within the packet buffer has been
adjusted to cover the packet mbuf structure.

Fan Zhang (4):
  librte_port: modify macros to access packet meta-data
  app/test: modify table and pipeline test
  app/test_pipeline: modify pipeline test
  librte_port: modify release notes and deprecation notice

 app/test-pipeline/main.h  |  2 ++
 app/test-pipeline/pipeline_hash.c | 34 ++-
 app/test-pipeline/pipeline_lpm.c  |  2 +-
 app/test-pipeline/pipeline_lpm_ipv6.c |  2 +-
 app/test/test_table.h |  8 +--
 app/test/test_table_combined.c| 28 +++---
 app/test/test_table_pipeline.c|  3 ++-
 app/test/test_table_tables.c  | 44 ++-
 doc/guides/rel_notes/deprecation.rst  |  5 
 doc/guides/rel_notes/release_2_2.rst  |  4 +++-
 lib/librte_port/Makefile  |  2 +-
 lib/librte_port/rte_port.h|  2 +-
 12 files changed, 72 insertions(+), 64 deletions(-)

--
2.1.0

[dpdk-dev] Debugging memory leak of mbufs

[Padam Jeet Singh]

Hello,

I have an application which in which the rte_mempool for packets associated 
with the network interfaces using IXGBE and IGB drivers is depleting slowly. 
Each time I do a throughput test, the number of free_count keeps reducing by 
10-15 entries, and finally completely exhausts.

Any inputs on how to debug such a situation? 

Thanks,
Padam

[dpdk-dev] [PATCH 0/4]librte_port: modify macros to access packet meta-data

[Dumitrescu, Cristian]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of
> roy.fan.zhang at intel.com
> Sent: Friday, September 11, 2015 4:36 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH 0/4]librte_port: modify macros to access packet
> meta-data
> 
> From: Fan Zhang 
> 
> This patchset links to ABI change announced for librte_port. Macros to
> access the packet meta-data stored within the packet buffer has been
> adjusted to cover the packet mbuf structure.
> 

Acked-by: Cristian Dumitrescu 

[dpdk-dev] vhost-net stops sending to virito pmd -- already fixed?

[Kyle Larose]

Hi all,

I've been debugging an issue we see occasionally when under load. We have a
non-DPDK linux-bridge host sending to our guest via vhost-net. The guest is
running a DPDK 1.8 application using virtio PMDs.

The symptoms of the problem are that host interfaces report all packets
sent to the interface as being tx-discarded. The guest reports that no
packets are received.

Debugging the guest process, I found that the PMD thought that there were
no entries queued for reception:

$5 = {hw = 0x7f131fcfd600, mz = 0x7f1346200128, virtio_net_hdr_mz = 0x0,
mpool = 0x7f131ff8a0c0, queue_id = 0, port_id = 1 '\001', vq_ring_virt_mem
= 0x7f1339ebd000, vq_alignment = 4096, vq_ring_size = 12288, vq_ring_mem =
2081148928, vq_ring = {num = 256,
desc = 0x7f1339ebd000, avail = 0x7f1339ebe000, used = 0x7f1339ebf000},
vq_free_cnt = 256, vq_nentries = 256, vq_queue_index = 0, vq_desc_head_idx
= 33, vq_desc_tail_idx = 32, vq_used_cons_idx = 37409, vq_avail_idx =
37409, virtio_net_hdr_mem = 0,
  packets = 67473953, bytes = 4049880780, errors = 0, vq_descx =
0x7f131fcf41d0}


(Basically, VIRTQUEUE_NUSED() was returning 0).

This makes me suspect that the guest and host fell out of sync.

Looking through the version tree for virtio_rxtx.c, I saw the following
commit:

http://dpdk.org/browse/dpdk/commit/lib/librte_pmd_virtio?id=8c09c20fb4cde76e53d87bd50acf2b441ecf6eb8

Does anybody know offhand if the issue fixed by that commit could be the
root cause of what I am seeing?

Thanks,

Kyle

[dpdk-dev] [PATCH v2 5/5] doc: modify release notes and deprecation notice for table and pipeline

[Maciej Gajdzica]

The LIBABIVER number is incremented for table and pipeline libraries.
The release notes is updated and the deprecation announce is removed.

Signed-off-by: Maciej Gajdzica 
---
 doc/guides/rel_notes/deprecation.rst |3 ---
 doc/guides/rel_notes/release_2_2.rst |6 --
 lib/librte_pipeline/Makefile |2 +-
 lib/librte_pipeline/rte_pipeline_version.map |8 
 lib/librte_table/Makefile|2 +-
 5 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/doc/guides/rel_notes/deprecation.rst 
b/doc/guides/rel_notes/deprecation.rst
index fffad80..5f46cf9 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -60,9 +60,6 @@ Deprecation Notices
 * librte_table LPM: A new parameter to hold the table name will be added to
   the LPM table parameter structure.

-* librte_table: New functions for table entry bulk add/delete will be added
-  to the table operations structure.
-
 * librte_table hash: Key mask parameter will be added to the hash table
   parameter structure for 8-byte key and 16-byte key extendible bucket and
   LRU tables.
diff --git a/doc/guides/rel_notes/release_2_2.rst 
b/doc/guides/rel_notes/release_2_2.rst
index 682f468..deb8e4e 100644
--- a/doc/guides/rel_notes/release_2_2.rst
+++ b/doc/guides/rel_notes/release_2_2.rst
@@ -47,6 +47,8 @@ ABI Changes

 * The LPM structure is changed. The deprecated field mem_location is removed.

+* Added functions add/delete bulk to table and pipeline libraries.
+

 Shared Library Versions
 ---
@@ -71,7 +73,7 @@ The libraries prepended with a plus sign were incremented in 
this version.
+ librte_mbuf.so.2
  librte_mempool.so.1
  librte_meter.so.1
- librte_pipeline.so.1
+   + librte_pipeline.so.2
  librte_pmd_bond.so.1
+ librte_pmd_ring.so.2
  librte_port.so.1
@@ -79,6 +81,6 @@ The libraries prepended with a plus sign were incremented in 
this version.
  librte_reorder.so.1
  librte_ring.so.1
  librte_sched.so.1
- librte_table.so.1
+   + librte_table.so.2
  librte_timer.so.1
  librte_vhost.so.1
diff --git a/lib/librte_pipeline/Makefile b/lib/librte_pipeline/Makefile
index 15e406b..1166d3c 100644
--- a/lib/librte_pipeline/Makefile
+++ b/lib/librte_pipeline/Makefile
@@ -41,7 +41,7 @@ CFLAGS += $(WERROR_FLAGS)

 EXPORT_MAP := rte_pipeline_version.map

-LIBABIVER := 1
+LIBABIVER := 2

 #
 # all source are stored in SRCS-y
diff --git a/lib/librte_pipeline/rte_pipeline_version.map 
b/lib/librte_pipeline/rte_pipeline_version.map
index 8f25d0f..5150070 100644
--- a/lib/librte_pipeline/rte_pipeline_version.map
+++ b/lib/librte_pipeline/rte_pipeline_version.map
@@ -29,3 +29,11 @@ DPDK_2.1 {
rte_pipeline_table_stats_read;

 } DPDK_2.0;
+
+DPDK_2.2 {
+   global:
+
+   rte_pipeline_table_entry_add_bulk;
+   rte_pipeline_table_entry_delete_bulk;
+
+} DPDK_2.1;
\ No newline at end of file
diff --git a/lib/librte_table/Makefile b/lib/librte_table/Makefile
index c5b3eaf..7f02af3 100644
--- a/lib/librte_table/Makefile
+++ b/lib/librte_table/Makefile
@@ -41,7 +41,7 @@ CFLAGS += $(WERROR_FLAGS)

 EXPORT_MAP := rte_table_version.map

-LIBABIVER := 1
+LIBABIVER := 2

 #
 # all source are stored in SRCS-y
-- 
1.7.9.5

[dpdk-dev] [PATCH v2 4/5] ip_pipeline: added cli commands for bulk add/delete to firewall pipeline

[Maciej Gajdzica]

Added two new cli commands to firewall pipeline. Commands bulk add and
bulk delete takes as argument a file with rules to add/delete. The file
is parsed, and then rules are passed to backend functions which
add/delete records from pipeline tables.

Signed-off-by: Maciej Gajdzica 
---
 examples/ip_pipeline/pipeline/pipeline_firewall.c  |  858 
 examples/ip_pipeline/pipeline/pipeline_firewall.h  |   14 +
 .../ip_pipeline/pipeline/pipeline_firewall_be.c|  157 
 .../ip_pipeline/pipeline/pipeline_firewall_be.h|   38 +
 4 files changed, 1067 insertions(+)

diff --git a/examples/ip_pipeline/pipeline/pipeline_firewall.c 
b/examples/ip_pipeline/pipeline/pipeline_firewall.c
index f6924ab..4137923 100644
--- a/examples/ip_pipeline/pipeline/pipeline_firewall.c
+++ b/examples/ip_pipeline/pipeline/pipeline_firewall.c
@@ -51,6 +51,8 @@
 #include "pipeline_common_fe.h"
 #include "pipeline_firewall.h"

+#define BUF_SIZE   1024
+
 struct app_pipeline_firewall_rule {
struct pipeline_firewall_key key;
int32_t priority;
@@ -73,6 +75,18 @@ struct app_pipeline_firewall {
void *default_rule_entry_ptr;
 };

+struct app_pipeline_add_bulk_params {
+   struct pipeline_firewall_key *keys;
+   uint32_t n_keys;
+   uint32_t *priorities;
+   uint32_t *port_ids;
+};
+
+struct app_pipeline_del_bulk_params {
+   struct pipeline_firewall_key *keys;
+   uint32_t n_keys;
+};
+
 static void
 print_firewall_ipv4_rule(struct app_pipeline_firewall_rule *rule)
 {
@@ -256,6 +270,358 @@ app_pipeline_firewall_key_check_and_normalize(struct 
pipeline_firewall_key *key)
}
 }

+static int
+app_pipeline_add_bulk_parse_file(char *filename,
+   struct app_pipeline_add_bulk_params *params)
+{
+   FILE *f;
+   char file_buf[BUF_SIZE];
+   uint32_t i;
+   int status = 0;
+
+   f = fopen(filename, "r");
+   if (f == NULL)
+   return -1;
+
+   params->n_keys = 0;
+   while (fgets(file_buf, BUF_SIZE, f) != NULL)
+   params->n_keys++;
+   rewind(f);
+
+   if (params->n_keys == 0) {
+   status = -1;
+   goto end;
+   }
+
+   params->keys = rte_malloc(NULL,
+   params->n_keys * sizeof(struct pipeline_firewall_key),
+   RTE_CACHE_LINE_SIZE);
+   if (params->keys == NULL) {
+   status = -1;
+   goto end;
+   }
+
+   params->priorities = rte_malloc(NULL,
+   params->n_keys * sizeof(uint32_t),
+   RTE_CACHE_LINE_SIZE);
+   if (params->priorities == NULL) {
+   status = -1;
+   goto end;
+   }
+
+   params->port_ids = rte_malloc(NULL,
+   params->n_keys * sizeof(uint32_t),
+   RTE_CACHE_LINE_SIZE);
+   if (params->port_ids == NULL) {
+   status = -1;
+   goto end;
+   }
+
+   i = 0;
+   while (fgets(file_buf, BUF_SIZE, f) != NULL) {
+   char *str;
+
+   str = strtok(file_buf, " ");
+   if (str == NULL) {
+   status = -1;
+   goto end;
+   }
+   params->priorities[i] = atoi(str);
+
+   str = strtok(NULL, " .");
+   if (str == NULL) {
+   status = -1;
+   goto end;
+   }
+   params->keys[i].key.ipv4_5tuple.src_ip = atoi(str)<<24;
+
+   str = strtok(NULL, " .");
+   if (str == NULL) {
+   status = -1;
+   goto end;
+   }
+   params->keys[i].key.ipv4_5tuple.src_ip |= atoi(str)<<16;
+
+   str = strtok(NULL, " .");
+   if (str == NULL) {
+   status = -1;
+   goto end;
+   }
+   params->keys[i].key.ipv4_5tuple.src_ip |= atoi(str)<<8;
+
+   str = strtok(NULL, " .");
+   if (str == NULL) {
+   status = -1;
+   goto end;
+   }
+   params->keys[i].key.ipv4_5tuple.src_ip |= atoi(str);
+
+   str = strtok(NULL, " ");
+   if (str == NULL) {
+   status = -1;
+   goto end;
+   }
+   params->keys[i].key.ipv4_5tuple.src_ip_mask = atoi(str);
+
+   str = strtok(NULL, " .");
+   if (str == NULL) {
+   status = -1;
+   goto end;
+   }
+   params->keys[i].key.ipv4_5tuple.dst_ip = atoi(str)<<24;
+
+   str = strtok(NULL, " .");
+   if (str == NULL) {
+   status = -1;
+   goto end;
+   }
+   params->keys[i].key.ipv4_5tuple.dst_ip |= atoi(str)<<16;
+
+ 

[dpdk-dev] [PATCH v2 3/5] test_table: added check for bulk add/delete to acl table unit test

[Maciej Gajdzica]

Added to acl table unit test check for bulk add and bulk delete.

Signed-off-by: Maciej Gajdzica 
---
 app/test/test_table_acl.c |  166 +
 1 file changed, 166 insertions(+)

diff --git a/app/test/test_table_acl.c b/app/test/test_table_acl.c
index e4e9b9c..fe8e545 100644
--- a/app/test/test_table_acl.c
+++ b/app/test/test_table_acl.c
@@ -253,6 +253,94 @@ parse_cb_ipv4_rule(char *str, struct 
rte_table_acl_rule_add_params *v)
return 0;
 }

+static int
+parse_cb_ipv4_rule_del(char *str, struct rte_table_acl_rule_delete_params *v)
+{
+   int i, rc;
+   char *s, *sp, *in[CB_FLD_NUM];
+   static const char *dlm = " \t\n";
+
+   /*
+   ** Skip leading '@'
+   */
+   if (strchr(str, '@') != str)
+   return -EINVAL;
+
+   s = str + 1;
+
+   /*
+   * Populate the 'in' array with the location of each
+   * field in the string we're parsing
+   */
+   for (i = 0; i != DIM(in); i++) {
+   in[i] = strtok_r(s, dlm, );
+   if (in[i] == NULL)
+   return -EINVAL;
+   s = NULL;
+   }
+
+   /* Parse x.x.x.x/x */
+   rc = parse_ipv4_net(in[CB_FLD_SRC_ADDR],
+   >field_value[SRC_FIELD_IPV4].value.u32,
+   >field_value[SRC_FIELD_IPV4].mask_range.u32);
+   if (rc != 0) {
+   RTE_LOG(ERR, PIPELINE, "failed to read src address/mask: %s\n",
+   in[CB_FLD_SRC_ADDR]);
+   return rc;
+   }
+
+   printf("V=%u, mask=%u\n", v->field_value[SRC_FIELD_IPV4].value.u32,
+   v->field_value[SRC_FIELD_IPV4].mask_range.u32);
+
+   /* Parse x.x.x.x/x */
+   rc = parse_ipv4_net(in[CB_FLD_DST_ADDR],
+   >field_value[DST_FIELD_IPV4].value.u32,
+   >field_value[DST_FIELD_IPV4].mask_range.u32);
+   if (rc != 0) {
+   RTE_LOG(ERR, PIPELINE, "failed to read dest address/mask: %s\n",
+   in[CB_FLD_DST_ADDR]);
+   return rc;
+   }
+
+   printf("V=%u, mask=%u\n", v->field_value[DST_FIELD_IPV4].value.u32,
+   v->field_value[DST_FIELD_IPV4].mask_range.u32);
+   /* Parse n:n */
+   rc = parse_port_range(in[CB_FLD_SRC_PORT_RANGE],
+   >field_value[SRCP_FIELD_IPV4].value.u16,
+   >field_value[SRCP_FIELD_IPV4].mask_range.u16);
+   if (rc != 0) {
+   RTE_LOG(ERR, PIPELINE, "failed to read source port range: %s\n",
+   in[CB_FLD_SRC_PORT_RANGE]);
+   return rc;
+   }
+
+   printf("V=%u, mask=%u\n", v->field_value[SRCP_FIELD_IPV4].value.u16,
+   v->field_value[SRCP_FIELD_IPV4].mask_range.u16);
+   /* Parse n:n */
+   rc = parse_port_range(in[CB_FLD_DST_PORT_RANGE],
+   >field_value[DSTP_FIELD_IPV4].value.u16,
+   >field_value[DSTP_FIELD_IPV4].mask_range.u16);
+   if (rc != 0) {
+   RTE_LOG(ERR, PIPELINE, "failed to read dest port range: %s\n",
+   in[CB_FLD_DST_PORT_RANGE]);
+   return rc;
+   }
+
+   printf("V=%u, mask=%u\n", v->field_value[DSTP_FIELD_IPV4].value.u16,
+   v->field_value[DSTP_FIELD_IPV4].mask_range.u16);
+   /* parse 0/0xnn */
+   GET_CB_FIELD(in[CB_FLD_PROTO],
+   v->field_value[PROTO_FIELD_IPV4].value.u8,
+   0, UINT8_MAX, '/');
+   GET_CB_FIELD(in[CB_FLD_PROTO],
+   v->field_value[PROTO_FIELD_IPV4].mask_range.u8,
+   0, UINT8_MAX, 0);
+
+   printf("V=%u, mask=%u\n",
+   (unsigned int)v->field_value[PROTO_FIELD_IPV4].value.u8,
+   v->field_value[PROTO_FIELD_IPV4].mask_range.u8);
+   return 0;
+}

 /*
  * The format for these rules DO NOT need the port ranges to be
@@ -393,6 +481,84 @@ setup_acl_pipeline(void)
}
}

+   /* Add bulk entries to tables */
+   for (i = 0; i < N_PORTS; i++) {
+   struct rte_table_acl_rule_add_params keys[5];
+   struct rte_pipeline_table_entry entries[5];
+   struct rte_table_acl_rule_add_params *key_array[5];
+   struct rte_pipeline_table_entry *table_entries[5];
+   int key_found[5];
+   struct rte_pipeline_table_entry *table_entries_ptr[5];
+   struct rte_pipeline_table_entry entries_ptr[5];
+
+   parser = parse_cb_ipv4_rule;
+   for (n = 0; n < 5; n++) {
+   memset([n], 0, sizeof(struct 
rte_table_acl_rule_add_params));
+   key_array[n] = [n];
+
+   snprintf(line, sizeof(line), "%s", lines[n]);
+   printf("PARSING [%s]\n", line);
+
+   ret = parser(line, [n]);
+   if (ret != 0) {
+   RTE_LOG(ERR, PIPELINE,
+   "line %u: parse_cb_ipv4vlan_rule"
+

[dpdk-dev] [PATCH v2 2/5] pipeline: added bulk add/delete functions for table

[Maciej Gajdzica]

Added functions for adding/deleting multiple records to table owned by
pipeline.

Signed-off-by: Maciej Gajdzica 
---
 lib/librte_pipeline/rte_pipeline.c |  106 
 lib/librte_pipeline/rte_pipeline.h |   62 +
 2 files changed, 168 insertions(+)

diff --git a/lib/librte_pipeline/rte_pipeline.c 
b/lib/librte_pipeline/rte_pipeline.c
index bd700d2..56022f4 100644
--- a/lib/librte_pipeline/rte_pipeline.c
+++ b/lib/librte_pipeline/rte_pipeline.c
@@ -587,6 +587,112 @@ rte_pipeline_table_entry_delete(struct rte_pipeline *p,
return (table->ops.f_delete)(table->h_table, key, key_found, entry);
 }

+int rte_pipeline_table_entry_add_bulk(struct rte_pipeline *p,
+   uint32_t table_id,
+   void **keys,
+   struct rte_pipeline_table_entry **entries,
+   uint32_t n_keys,
+   int *key_found,
+   struct rte_pipeline_table_entry **entries_ptr)
+{
+   struct rte_table *table;
+   uint32_t i;
+
+   /* Check input arguments */
+   if (p == NULL) {
+   RTE_LOG(ERR, PIPELINE, "%s: pipeline parameter is NULL\n",
+   __func__);
+   return -EINVAL;
+   }
+
+   if (keys == NULL) {
+   RTE_LOG(ERR, PIPELINE, "%s: keys parameter is NULL\n", 
__func__);
+   return -EINVAL;
+   }
+
+   if (entries == NULL) {
+   RTE_LOG(ERR, PIPELINE, "%s: entries parameter is NULL\n",
+   __func__);
+   return -EINVAL;
+   }
+
+   if (table_id >= p->num_tables) {
+   RTE_LOG(ERR, PIPELINE,
+   "%s: table_id %d out of range\n", __func__, table_id);
+   return -EINVAL;
+   }
+
+   table = >tables[table_id];
+
+   if (table->ops.f_add_bulk == NULL) {
+   RTE_LOG(ERR, PIPELINE, "%s: f_add_bulk function pointer NULL\n",
+   __func__);
+   return -EINVAL;
+   }
+
+   for (i = 0; i < n_keys; i++) {
+   if ((entries[i]->action == RTE_PIPELINE_ACTION_TABLE) &&
+   table->table_next_id_valid &&
+   (entries[i]->table_id != table->table_next_id)) {
+   RTE_LOG(ERR, PIPELINE,
+   "%s: Tree-like topologies not allowed\n", 
__func__);
+   return -EINVAL;
+   }
+   }
+
+   /* Add entry */
+   for (i = 0; i < n_keys; i++) {
+   if ((entries[i]->action == RTE_PIPELINE_ACTION_TABLE) &&
+   (table->table_next_id_valid == 0)) {
+   table->table_next_id = entries[i]->table_id;
+   table->table_next_id_valid = 1;
+   }
+   }
+
+   return (table->ops.f_add_bulk)(table->h_table, keys, (void **) entries,
+   n_keys, key_found, (void **) entries_ptr);
+}
+
+int rte_pipeline_table_entry_delete_bulk(struct rte_pipeline *p,
+   uint32_t table_id,
+   void **keys,
+   uint32_t n_keys,
+   int *key_found,
+   struct rte_pipeline_table_entry **entries)
+{
+   struct rte_table *table;
+
+   /* Check input arguments */
+   if (p == NULL) {
+   RTE_LOG(ERR, PIPELINE, "%s: pipeline parameter NULL\n",
+   __func__);
+   return -EINVAL;
+   }
+
+   if (keys == NULL) {
+   RTE_LOG(ERR, PIPELINE, "%s: key parameter is NULL\n",
+   __func__);
+   return -EINVAL;
+   }
+
+   if (table_id >= p->num_tables) {
+   RTE_LOG(ERR, PIPELINE,
+   "%s: table_id %d out of range\n", __func__, table_id);
+   return -EINVAL;
+   }
+
+   table = >tables[table_id];
+
+   if (table->ops.f_delete_bulk == NULL) {
+   RTE_LOG(ERR, PIPELINE,
+   "%s: f_delete function pointer NULL\n", __func__);
+   return -EINVAL;
+   }
+
+   return (table->ops.f_delete_bulk)(table->h_table, keys, n_keys, 
key_found,
+   (void **) entries);
+}
+
 /*
  * Port
  *
diff --git a/lib/librte_pipeline/rte_pipeline.h 
b/lib/librte_pipeline/rte_pipeline.h
index 59e0710..ef4622f 100644
--- a/lib/librte_pipeline/rte_pipeline.h
+++ b/lib/librte_pipeline/rte_pipeline.h
@@ -466,6 +466,68 @@ int rte_pipeline_table_entry_delete(struct rte_pipeline *p,
struct rte_pipeline_table_entry *entry);

 /**
+ * Pipeline table entry add bulk
+ *
+ * @param p
+ *   Handle to pipeline instance
+ * @param table_id
+ *   Table ID (returned by previous invocation of pipeline table create)
+ * @param keys
+ *   Array containing table entry keys
+ * @param entries
+ *   Array containung new contents for every table entry identified by key
+ * @param n_keys
+ *   Number of keys to add
+ * @param key_found
+ *   On successful invocation, key_found for every item in the array is set to
+ *   TRUE (value different 

[dpdk-dev] [PATCH v2 1/5] table: added bulk add/delete functions for table

[Maciej Gajdzica]

New functions prototypes for bulk add/delete added to table API. New
functions allows adding/deleting multiple records with single function
call. For now those functions are implemented only for ACL table. For
other tables these function pointers are set to NULL.

Signed-off-by: Maciej Gajdzica 
---
 lib/librte_table/rte_table.h|   85 -
 lib/librte_table/rte_table_acl.c|  309 +++
 lib/librte_table/rte_table_array.c  |2 +
 lib/librte_table/rte_table_hash_ext.c   |4 +
 lib/librte_table/rte_table_hash_key16.c |4 +
 lib/librte_table/rte_table_hash_key32.c |4 +
 lib/librte_table/rte_table_hash_key8.c  |8 +
 lib/librte_table/rte_table_hash_lru.c   |4 +
 lib/librte_table/rte_table_lpm.c|2 +
 lib/librte_table/rte_table_lpm_ipv6.c   |2 +
 lib/librte_table/rte_table_stub.c   |2 +
 11 files changed, 420 insertions(+), 6 deletions(-)

diff --git a/lib/librte_table/rte_table.h b/lib/librte_table/rte_table.h
index c13d40d..720514e 100644
--- a/lib/librte_table/rte_table.h
+++ b/lib/librte_table/rte_table.h
@@ -154,6 +154,77 @@ typedef int (*rte_table_op_entry_delete)(
void *entry);

 /**
+ * Lookup table entry add bulk
+ *
+ * @param table
+ *   Handle to lookup table instance
+ * @param key
+ *   Array containing lookup keys
+ * @param entries
+ *   Array containing data to be associated with each key. Every item in the
+ *   array has to point to a valid memory buffer where the first entry_size
+ *   bytes (table create parameter) are populated with the data.
+ * @param n_keys
+ *   Number of keys to add
+ * @param key_found
+ *   After successful invocation, key_found for every item in the array is set
+ *   to a value different than 0 if the current key is already present in the
+ *   table and to 0 if not. This pointer has to be set to a valid memory
+ *   location before the table entry add function is called.
+ * @param entries_ptr
+ *   After successful invocation, array *entries_ptr stores the handle to the
+ *   table entry containing the data associated with every key. This handle can
+ *   be used to perform further read-write accesses to this entry. This handle
+ *   is valid until the key is deleted from the table or the same key is
+ *   re-added to the table, typically to associate it with different data. This
+ *   pointer has to be set to a valid memory location before the function is
+ *   called.
+ * @return
+ *   0 on success, error code otherwise
+ */
+typedef int (*rte_table_op_entry_add_bulk)(
+   void *table,
+   void **keys,
+   void **entries,
+   uint32_t n_keys,
+   int *key_found,
+   void **entries_ptr);
+
+/**
+ * Lookup table entry delete bulk
+ *
+ * @param table
+ *   Handle to lookup table instance
+ * @param key
+ *   Array containing lookup keys
+ * @param n_keys
+ *   Number of keys to delete
+ * @param key_found
+ *   After successful invocation, key_found for every item in the array is set
+ *   to a value different than 0if the current key was present in the table
+ *   before the delete operation was performed and to 0 if not. This pointer
+ *   has to be set to a valid memory location before the table entry delete
+ *   function is called.
+ * @param entries
+ *   If entries pointer is NULL, this pointer is ignored for every entry found.
+ *   Else, after successful invocation, if specific key is found in the table
+ *   (key_found is different than 0 for this item after function call is
+ *   completed) and item of entry array points to a valid buffer (entry is set
+ *   to a value different than NULL before the function is called), then the
+ *   first entry_size bytes (table create parameter) in *entry store a copy of
+ *   table entry that contained the data associated with the current key before
+ *   the key was deleted.
+ * @return
+ *   0 on success, error code otherwise
+ */
+typedef int (*rte_table_op_entry_delete_bulk)(
+   void *table,
+   void **keys,
+   uint32_t n_keys,
+   int *key_found,
+   void **entries);
+
+/**
  * Lookup table lookup
  *
  * @param table
@@ -213,12 +284,14 @@ typedef int (*rte_table_op_stats_read)(

 /** Lookup table interface defining the lookup table operation */
 struct rte_table_ops {
-   rte_table_op_create f_create;   /**< Create */
-   rte_table_op_free f_free;   /**< Free */
-   rte_table_op_entry_add f_add;   /**< Entry add */
-   rte_table_op_entry_delete f_delete; /**< Entry delete */
-   rte_table_op_lookup f_lookup;   /**< Lookup */
-   rte_table_op_stats_read f_stats;/**< Stats */
+   rte_table_op_create f_create; /**< Create */
+   rte_table_op_free f_free; /**< Free */
+   rte_table_op_entry_add f_add; /**< Entry add */
+   rte_table_op_entry_delete f_delete;   /**< Entry delete */
+   rte_table_op_entry_add_bulk f_add_bulk;   /**< 

[dpdk-dev] [PATCH v2 0/5] pipeline: add bulk add/delete functions for table

[Maciej Gajdzica]

This patch adds bulk add/delete functions for tables used by pipelines. It
allows for adding/deleting many rules to pipeline tables in one function call.
It is particulary useful for firewall pipeline which is using ACL table. After
every add or delete, table is rebuild which leads to very long times when
trying to add/delete many entries.

Maciej Gajdzica (5):
  table: added bulk add/delete functions for table
  pipeline: added bulk add/delete functions for table
  test_table: added check for bulk add/delete to acl table unit test
  ip_pipeline: added cli commands for bulk add/delete to firewall
pipeline
  doc: modify release notes and deprecation notice for table and
pipeline

 app/test/test_table_acl.c  |  166 
 doc/guides/rel_notes/deprecation.rst   |3 -
 doc/guides/rel_notes/release_2_2.rst   |6 +-
 examples/ip_pipeline/pipeline/pipeline_firewall.c  |  858 
 examples/ip_pipeline/pipeline/pipeline_firewall.h  |   14 +
 .../ip_pipeline/pipeline/pipeline_firewall_be.c|  157 
 .../ip_pipeline/pipeline/pipeline_firewall_be.h|   38 +
 lib/librte_pipeline/Makefile   |2 +-
 lib/librte_pipeline/rte_pipeline.c |  106 +++
 lib/librte_pipeline/rte_pipeline.h |   62 ++
 lib/librte_pipeline/rte_pipeline_version.map   |8 +
 lib/librte_table/Makefile  |2 +-
 lib/librte_table/rte_table.h   |   85 +-
 lib/librte_table/rte_table_acl.c   |  309 +++
 lib/librte_table/rte_table_array.c |2 +
 lib/librte_table/rte_table_hash_ext.c  |4 +
 lib/librte_table/rte_table_hash_key16.c|4 +
 lib/librte_table/rte_table_hash_key32.c|4 +
 lib/librte_table/rte_table_hash_key8.c |8 +
 lib/librte_table/rte_table_hash_lru.c  |4 +
 lib/librte_table/rte_table_lpm.c   |2 +
 lib/librte_table/rte_table_lpm_ipv6.c  |2 +
 lib/librte_table/rte_table_stub.c  |2 +
 23 files changed, 1835 insertions(+), 13 deletions(-)

-- 
1.7.9.5

[dpdk-dev] [PATCH 1/2] rte_sched: whitespace cleanup

[Stephen Hemminger]

On Fri, 11 Sep 2015 17:31:10 +
"Dumitrescu, Cristian"  wrote:

> >   *   p00  ___   p10  ___   p20  ___   p30  ___
> > - * ->|   |->|   |->|   |->|   |->
> > + *->|   |->|   |->|   |->|   |->
> >   *   |   0   |  |   1   |  |   2   |  |   3   |
> > - * ->|___|->|___|->|___|->|___|->
> > + *->|___|->|___|->|___|->|___|->
> >   *   p01p11p21p31
> >   *
> >   ***/  
> 
> You are breaking the ASCII diagram above by removing the first space on the 
> line, but not for all lines. Please check that diagram is OK after the space 
> removal.

Sorry, it was global repace issue.

[dpdk-dev] [PATCH 2/2] rte_sched: remove useless bitmap_free

[Stephen Hemminger]

> Hi Steve,
> 
> I agree these functions are not doing much at the moment, but I would like to 
> keep them for the reasons below:
> 
> 1. There might be people using them, and we do not want to break their code. 
> Removing them is an ABI change.
> 
> 2. Although they are just placeholders for now, we might need to add more 
> functionality to them going forward, as the implementation evolves. I don't 
> want to change the API now by removing them, and change the API later when we 
> need to add them back. Generally, I think it is good practice to have free 
> functions.

The source code base is not a code repository for unused and dead code!
If you need to keep things, either get them out of previous history with git
or keep them out of tree.

Also have a number of patches to remove all #ifdef code that is dead
in QoS now.

[dpdk-dev] [PATCH] doc: add guideline for updating release notes

[John McNamara]

>From version 2.2 of DPDK onwards patchsets should include
updates to the Release Notes for additions, fixes and
changes.

Add guideline on what to update in the Release Notes to the
Documentation Contribution guidelines.

Signed-off-by: John McNamara 
---
 doc/guides/contributing/documentation.rst | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/doc/guides/contributing/documentation.rst 
b/doc/guides/contributing/documentation.rst
index cb5ca0d..7c1eb41 100644
--- a/doc/guides/contributing/documentation.rst
+++ b/doc/guides/contributing/documentation.rst
@@ -63,9 +63,20 @@ added to by the developer.
   any known issues.
   The Releases Notes also contain notifications of features that will change 
ABI compatibility in the next major release.

-  Developers should update the Release Notes to add a short description of new 
or updated features.
-  Developers should also update the Release Notes to add ABI announcements if 
necessary,
-  (see :doc:`/contributing/versioning` for details).
+  Developers should include updates to the Release Notes with patch sets that 
relate to any of the following sections:
+
+  * New Features
+  * Resolved Issues (see below)
+  * Known Issues
+  * API Changes
+  * ABI Changes
+  * Shared Library Versions
+
+  Resolved Issues should only include issues from previous releases that have 
been resolved in the current release.
+  Issues that are introduced and then fixed within a release cycle do not have 
to be included here.
+
+  Refer to the Release Notes from the previous DPDK release for the correct 
format of each section.
+

 * **API documentation**

-- 
1.8.1.4

[dpdk-dev] testpmd - configuration of the fdir filter

[Navneet Rao]

I'm getting a fdir filter programming error after I do this --





./testpmd -c  -n 4 -- -i --pkt-filter-mode=perfect --rxq=2 --txq=2 
--portmask=0x3 --nb-ports=2 --disable-rss



   testpmd> port stop all

   testpmd> flow_director_mask 0 vlan 0xefff src_mask 255.255.255.255 
::::::: 0x dst_mask 255.255.255.255 
::::::: 0x

   testpmd> flow_director_filter 0 add flow ipv4-udp src 192.168.10.100 dst 
192.168.10.101 vlan 0x1 flexbytes (0x00,0x00) fwd queue 1 fd_id 1

   PMD: fdir_write_perfect_filter_82599(): Rx Queue=1 hash=10529

   PMD: fdir_write_perfect_filter_82599(): Timeout writing flow director filter.

   PMD: ixgbe_add_del_fdir_filter(): Fail to add FDIR filter!

   flow director programming error: (Connection timed out)





Any ideas? Debug?



Thanks

-Navneet









-Original Message-
From: Navneet Rao 
Sent: Wednesday, September 09, 2015 10:26 AM
To: Jan Fruhbauer
Subject: RE: [dpdk-dev] testpmd - configuration of the fdir filter



Hello Jan:



Please let me know if you were able to figure this out...

I am also running into similar issues!!!



Thanks

-Navneet





-Original Message-

From: Jan Fruhbauer [mailto:fruhba...@invea.com] 

Sent: Friday, September 04, 2015 3:46 AM

To: HYPERLINK "mailto:dev at dpdk.org"dev at dpdk.org

Subject: [dpdk-dev] testpmd - configuration of the fdir filter



Hi,



I want to use the fdir filtering on a NIC based on the Intel 82599. I have 
tested the testpmd application. I configured masks and added a filter but the 
fdir filter never matched any packet. I even tried different masks and filters 
(with/without ports, TCP/UDP flow, IP prefixes, ...), but it never worked. Here 
is an example of commands I used during testing:



./testpmd -c 0xff -n 2 -- -i --rxq=2 --txq=2 --pkt-filter-mode=perfect

--portmask=0x3 --nb-ports=2 --disable-rss

testpmd> port stop 0

testpmd> flow_director_mask 0 vlan 0x src_mask 255.255.255.255

::::::: 0x dst_mask 255.255.255.255 
::::::: 0x

testpmd> flow_director_flex_mask 0 flow all

(0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0)

testpmd> port start 0

testpmd> flow_director_filter 0 add flow ipv4-tcp src 1.0.0.1 1 dst

2.0.0.1 1 vlan 0x0 flexbytes (0x00,0x00) fwd queue 1 fd_id 1

testpmd> start



Then I sent generated traffic (simple packets with ethernet/IP/TCP

headers) with parametrs I specified in the flow_director_filter to the NIC port 
0 and all packets arrived to the queue 0.



Please, could you advise me what I am doing wrong? Maybe some other 
configuration I didn't notice?



Regards,

Jan

[dpdk-dev] [PATCH 4/4] ip_pipeline: added cli commands for bulk add/delete to firewall pipeline

[Maciej Gajdzica]

Added two new cli commands to firewall pipeline. Commands bulk add and
bulk delete takes as argument a file with rules to add/delete. The file
is parsed, and then rules are passed to backend functions which
add/delete records from pipeline tables.

Signed-off-by: Maciej Gajdzica 
---
 examples/ip_pipeline/pipeline/pipeline_firewall.c  |  858 
 examples/ip_pipeline/pipeline/pipeline_firewall.h  |   14 +
 .../ip_pipeline/pipeline/pipeline_firewall_be.c|  157 
 .../ip_pipeline/pipeline/pipeline_firewall_be.h|   38 +
 4 files changed, 1067 insertions(+)

diff --git a/examples/ip_pipeline/pipeline/pipeline_firewall.c 
b/examples/ip_pipeline/pipeline/pipeline_firewall.c
index f6924ab..4137923 100644
--- a/examples/ip_pipeline/pipeline/pipeline_firewall.c
+++ b/examples/ip_pipeline/pipeline/pipeline_firewall.c
@@ -51,6 +51,8 @@
 #include "pipeline_common_fe.h"
 #include "pipeline_firewall.h"

+#define BUF_SIZE   1024
+
 struct app_pipeline_firewall_rule {
struct pipeline_firewall_key key;
int32_t priority;
@@ -73,6 +75,18 @@ struct app_pipeline_firewall {
void *default_rule_entry_ptr;
 };

+struct app_pipeline_add_bulk_params {
+   struct pipeline_firewall_key *keys;
+   uint32_t n_keys;
+   uint32_t *priorities;
+   uint32_t *port_ids;
+};
+
+struct app_pipeline_del_bulk_params {
+   struct pipeline_firewall_key *keys;
+   uint32_t n_keys;
+};
+
 static void
 print_firewall_ipv4_rule(struct app_pipeline_firewall_rule *rule)
 {
@@ -256,6 +270,358 @@ app_pipeline_firewall_key_check_and_normalize(struct 
pipeline_firewall_key *key)
}
 }

+static int
+app_pipeline_add_bulk_parse_file(char *filename,
+   struct app_pipeline_add_bulk_params *params)
+{
+   FILE *f;
+   char file_buf[BUF_SIZE];
+   uint32_t i;
+   int status = 0;
+
+   f = fopen(filename, "r");
+   if (f == NULL)
+   return -1;
+
+   params->n_keys = 0;
+   while (fgets(file_buf, BUF_SIZE, f) != NULL)
+   params->n_keys++;
+   rewind(f);
+
+   if (params->n_keys == 0) {
+   status = -1;
+   goto end;
+   }
+
+   params->keys = rte_malloc(NULL,
+   params->n_keys * sizeof(struct pipeline_firewall_key),
+   RTE_CACHE_LINE_SIZE);
+   if (params->keys == NULL) {
+   status = -1;
+   goto end;
+   }
+
+   params->priorities = rte_malloc(NULL,
+   params->n_keys * sizeof(uint32_t),
+   RTE_CACHE_LINE_SIZE);
+   if (params->priorities == NULL) {
+   status = -1;
+   goto end;
+   }
+
+   params->port_ids = rte_malloc(NULL,
+   params->n_keys * sizeof(uint32_t),
+   RTE_CACHE_LINE_SIZE);
+   if (params->port_ids == NULL) {
+   status = -1;
+   goto end;
+   }
+
+   i = 0;
+   while (fgets(file_buf, BUF_SIZE, f) != NULL) {
+   char *str;
+
+   str = strtok(file_buf, " ");
+   if (str == NULL) {
+   status = -1;
+   goto end;
+   }
+   params->priorities[i] = atoi(str);
+
+   str = strtok(NULL, " .");
+   if (str == NULL) {
+   status = -1;
+   goto end;
+   }
+   params->keys[i].key.ipv4_5tuple.src_ip = atoi(str)<<24;
+
+   str = strtok(NULL, " .");
+   if (str == NULL) {
+   status = -1;
+   goto end;
+   }
+   params->keys[i].key.ipv4_5tuple.src_ip |= atoi(str)<<16;
+
+   str = strtok(NULL, " .");
+   if (str == NULL) {
+   status = -1;
+   goto end;
+   }
+   params->keys[i].key.ipv4_5tuple.src_ip |= atoi(str)<<8;
+
+   str = strtok(NULL, " .");
+   if (str == NULL) {
+   status = -1;
+   goto end;
+   }
+   params->keys[i].key.ipv4_5tuple.src_ip |= atoi(str);
+
+   str = strtok(NULL, " ");
+   if (str == NULL) {
+   status = -1;
+   goto end;
+   }
+   params->keys[i].key.ipv4_5tuple.src_ip_mask = atoi(str);
+
+   str = strtok(NULL, " .");
+   if (str == NULL) {
+   status = -1;
+   goto end;
+   }
+   params->keys[i].key.ipv4_5tuple.dst_ip = atoi(str)<<24;
+
+   str = strtok(NULL, " .");
+   if (str == NULL) {
+   status = -1;
+   goto end;
+   }
+   params->keys[i].key.ipv4_5tuple.dst_ip |= atoi(str)<<16;
+
+ 

[dpdk-dev] [PATCH 3/4] test_table: added check for bulk add/delete to acl table unit test

[Maciej Gajdzica]

Added to acl table unit test check for bulk add and bulk delete.

Signed-off-by: Maciej Gajdzica 
---
 app/test/test_table_acl.c |  166 +
 1 file changed, 166 insertions(+)

diff --git a/app/test/test_table_acl.c b/app/test/test_table_acl.c
index e4e9b9c..fe8e545 100644
--- a/app/test/test_table_acl.c
+++ b/app/test/test_table_acl.c
@@ -253,6 +253,94 @@ parse_cb_ipv4_rule(char *str, struct 
rte_table_acl_rule_add_params *v)
return 0;
 }

+static int
+parse_cb_ipv4_rule_del(char *str, struct rte_table_acl_rule_delete_params *v)
+{
+   int i, rc;
+   char *s, *sp, *in[CB_FLD_NUM];
+   static const char *dlm = " \t\n";
+
+   /*
+   ** Skip leading '@'
+   */
+   if (strchr(str, '@') != str)
+   return -EINVAL;
+
+   s = str + 1;
+
+   /*
+   * Populate the 'in' array with the location of each
+   * field in the string we're parsing
+   */
+   for (i = 0; i != DIM(in); i++) {
+   in[i] = strtok_r(s, dlm, );
+   if (in[i] == NULL)
+   return -EINVAL;
+   s = NULL;
+   }
+
+   /* Parse x.x.x.x/x */
+   rc = parse_ipv4_net(in[CB_FLD_SRC_ADDR],
+   >field_value[SRC_FIELD_IPV4].value.u32,
+   >field_value[SRC_FIELD_IPV4].mask_range.u32);
+   if (rc != 0) {
+   RTE_LOG(ERR, PIPELINE, "failed to read src address/mask: %s\n",
+   in[CB_FLD_SRC_ADDR]);
+   return rc;
+   }
+
+   printf("V=%u, mask=%u\n", v->field_value[SRC_FIELD_IPV4].value.u32,
+   v->field_value[SRC_FIELD_IPV4].mask_range.u32);
+
+   /* Parse x.x.x.x/x */
+   rc = parse_ipv4_net(in[CB_FLD_DST_ADDR],
+   >field_value[DST_FIELD_IPV4].value.u32,
+   >field_value[DST_FIELD_IPV4].mask_range.u32);
+   if (rc != 0) {
+   RTE_LOG(ERR, PIPELINE, "failed to read dest address/mask: %s\n",
+   in[CB_FLD_DST_ADDR]);
+   return rc;
+   }
+
+   printf("V=%u, mask=%u\n", v->field_value[DST_FIELD_IPV4].value.u32,
+   v->field_value[DST_FIELD_IPV4].mask_range.u32);
+   /* Parse n:n */
+   rc = parse_port_range(in[CB_FLD_SRC_PORT_RANGE],
+   >field_value[SRCP_FIELD_IPV4].value.u16,
+   >field_value[SRCP_FIELD_IPV4].mask_range.u16);
+   if (rc != 0) {
+   RTE_LOG(ERR, PIPELINE, "failed to read source port range: %s\n",
+   in[CB_FLD_SRC_PORT_RANGE]);
+   return rc;
+   }
+
+   printf("V=%u, mask=%u\n", v->field_value[SRCP_FIELD_IPV4].value.u16,
+   v->field_value[SRCP_FIELD_IPV4].mask_range.u16);
+   /* Parse n:n */
+   rc = parse_port_range(in[CB_FLD_DST_PORT_RANGE],
+   >field_value[DSTP_FIELD_IPV4].value.u16,
+   >field_value[DSTP_FIELD_IPV4].mask_range.u16);
+   if (rc != 0) {
+   RTE_LOG(ERR, PIPELINE, "failed to read dest port range: %s\n",
+   in[CB_FLD_DST_PORT_RANGE]);
+   return rc;
+   }
+
+   printf("V=%u, mask=%u\n", v->field_value[DSTP_FIELD_IPV4].value.u16,
+   v->field_value[DSTP_FIELD_IPV4].mask_range.u16);
+   /* parse 0/0xnn */
+   GET_CB_FIELD(in[CB_FLD_PROTO],
+   v->field_value[PROTO_FIELD_IPV4].value.u8,
+   0, UINT8_MAX, '/');
+   GET_CB_FIELD(in[CB_FLD_PROTO],
+   v->field_value[PROTO_FIELD_IPV4].mask_range.u8,
+   0, UINT8_MAX, 0);
+
+   printf("V=%u, mask=%u\n",
+   (unsigned int)v->field_value[PROTO_FIELD_IPV4].value.u8,
+   v->field_value[PROTO_FIELD_IPV4].mask_range.u8);
+   return 0;
+}

 /*
  * The format for these rules DO NOT need the port ranges to be
@@ -393,6 +481,84 @@ setup_acl_pipeline(void)
}
}

+   /* Add bulk entries to tables */
+   for (i = 0; i < N_PORTS; i++) {
+   struct rte_table_acl_rule_add_params keys[5];
+   struct rte_pipeline_table_entry entries[5];
+   struct rte_table_acl_rule_add_params *key_array[5];
+   struct rte_pipeline_table_entry *table_entries[5];
+   int key_found[5];
+   struct rte_pipeline_table_entry *table_entries_ptr[5];
+   struct rte_pipeline_table_entry entries_ptr[5];
+
+   parser = parse_cb_ipv4_rule;
+   for (n = 0; n < 5; n++) {
+   memset([n], 0, sizeof(struct 
rte_table_acl_rule_add_params));
+   key_array[n] = [n];
+
+   snprintf(line, sizeof(line), "%s", lines[n]);
+   printf("PARSING [%s]\n", line);
+
+   ret = parser(line, [n]);
+   if (ret != 0) {
+   RTE_LOG(ERR, PIPELINE,
+   "line %u: parse_cb_ipv4vlan_rule"
+

[dpdk-dev] [PATCH 2/4] pipeline: added bulk add/delete functions for table

[Maciej Gajdzica]

Added functions for adding/deleting multiple records to table owned by
pipeline.

Signed-off-by: Maciej Gajdzica 
---
 lib/librte_pipeline/rte_pipeline.c |  106 
 lib/librte_pipeline/rte_pipeline.h |   62 +
 2 files changed, 168 insertions(+)

diff --git a/lib/librte_pipeline/rte_pipeline.c 
b/lib/librte_pipeline/rte_pipeline.c
index bd700d2..56022f4 100644
--- a/lib/librte_pipeline/rte_pipeline.c
+++ b/lib/librte_pipeline/rte_pipeline.c
@@ -587,6 +587,112 @@ rte_pipeline_table_entry_delete(struct rte_pipeline *p,
return (table->ops.f_delete)(table->h_table, key, key_found, entry);
 }

+int rte_pipeline_table_entry_add_bulk(struct rte_pipeline *p,
+   uint32_t table_id,
+   void **keys,
+   struct rte_pipeline_table_entry **entries,
+   uint32_t n_keys,
+   int *key_found,
+   struct rte_pipeline_table_entry **entries_ptr)
+{
+   struct rte_table *table;
+   uint32_t i;
+
+   /* Check input arguments */
+   if (p == NULL) {
+   RTE_LOG(ERR, PIPELINE, "%s: pipeline parameter is NULL\n",
+   __func__);
+   return -EINVAL;
+   }
+
+   if (keys == NULL) {
+   RTE_LOG(ERR, PIPELINE, "%s: keys parameter is NULL\n", 
__func__);
+   return -EINVAL;
+   }
+
+   if (entries == NULL) {
+   RTE_LOG(ERR, PIPELINE, "%s: entries parameter is NULL\n",
+   __func__);
+   return -EINVAL;
+   }
+
+   if (table_id >= p->num_tables) {
+   RTE_LOG(ERR, PIPELINE,
+   "%s: table_id %d out of range\n", __func__, table_id);
+   return -EINVAL;
+   }
+
+   table = >tables[table_id];
+
+   if (table->ops.f_add_bulk == NULL) {
+   RTE_LOG(ERR, PIPELINE, "%s: f_add_bulk function pointer NULL\n",
+   __func__);
+   return -EINVAL;
+   }
+
+   for (i = 0; i < n_keys; i++) {
+   if ((entries[i]->action == RTE_PIPELINE_ACTION_TABLE) &&
+   table->table_next_id_valid &&
+   (entries[i]->table_id != table->table_next_id)) {
+   RTE_LOG(ERR, PIPELINE,
+   "%s: Tree-like topologies not allowed\n", 
__func__);
+   return -EINVAL;
+   }
+   }
+
+   /* Add entry */
+   for (i = 0; i < n_keys; i++) {
+   if ((entries[i]->action == RTE_PIPELINE_ACTION_TABLE) &&
+   (table->table_next_id_valid == 0)) {
+   table->table_next_id = entries[i]->table_id;
+   table->table_next_id_valid = 1;
+   }
+   }
+
+   return (table->ops.f_add_bulk)(table->h_table, keys, (void **) entries,
+   n_keys, key_found, (void **) entries_ptr);
+}
+
+int rte_pipeline_table_entry_delete_bulk(struct rte_pipeline *p,
+   uint32_t table_id,
+   void **keys,
+   uint32_t n_keys,
+   int *key_found,
+   struct rte_pipeline_table_entry **entries)
+{
+   struct rte_table *table;
+
+   /* Check input arguments */
+   if (p == NULL) {
+   RTE_LOG(ERR, PIPELINE, "%s: pipeline parameter NULL\n",
+   __func__);
+   return -EINVAL;
+   }
+
+   if (keys == NULL) {
+   RTE_LOG(ERR, PIPELINE, "%s: key parameter is NULL\n",
+   __func__);
+   return -EINVAL;
+   }
+
+   if (table_id >= p->num_tables) {
+   RTE_LOG(ERR, PIPELINE,
+   "%s: table_id %d out of range\n", __func__, table_id);
+   return -EINVAL;
+   }
+
+   table = >tables[table_id];
+
+   if (table->ops.f_delete_bulk == NULL) {
+   RTE_LOG(ERR, PIPELINE,
+   "%s: f_delete function pointer NULL\n", __func__);
+   return -EINVAL;
+   }
+
+   return (table->ops.f_delete_bulk)(table->h_table, keys, n_keys, 
key_found,
+   (void **) entries);
+}
+
 /*
  * Port
  *
diff --git a/lib/librte_pipeline/rte_pipeline.h 
b/lib/librte_pipeline/rte_pipeline.h
index 59e0710..ef4622f 100644
--- a/lib/librte_pipeline/rte_pipeline.h
+++ b/lib/librte_pipeline/rte_pipeline.h
@@ -466,6 +466,68 @@ int rte_pipeline_table_entry_delete(struct rte_pipeline *p,
struct rte_pipeline_table_entry *entry);

 /**
+ * Pipeline table entry add bulk
+ *
+ * @param p
+ *   Handle to pipeline instance
+ * @param table_id
+ *   Table ID (returned by previous invocation of pipeline table create)
+ * @param keys
+ *   Array containing table entry keys
+ * @param entries
+ *   Array containung new contents for every table entry identified by key
+ * @param n_keys
+ *   Number of keys to add
+ * @param key_found
+ *   On successful invocation, key_found for every item in the array is set to
+ *   TRUE (value different 

[dpdk-dev] [PATCH 1/4] table: added bulk add/delete functions for table

[Maciej Gajdzica]

New functions prototypes for bulk add/delete added to table API. New
functions allows adding/deleting multiple records with single function
call. For now those functions are implemented only for ACL table. For
other tables these function pointers are set to NULL.

Signed-off-by: Maciej Gajdzica 
---
 lib/librte_table/rte_table.h|   85 -
 lib/librte_table/rte_table_acl.c|  309 +++
 lib/librte_table/rte_table_array.c  |2 +
 lib/librte_table/rte_table_hash_ext.c   |4 +
 lib/librte_table/rte_table_hash_key16.c |4 +
 lib/librte_table/rte_table_hash_key32.c |4 +
 lib/librte_table/rte_table_hash_key8.c  |8 +
 lib/librte_table/rte_table_hash_lru.c   |4 +
 lib/librte_table/rte_table_lpm.c|2 +
 lib/librte_table/rte_table_lpm_ipv6.c   |2 +
 lib/librte_table/rte_table_stub.c   |2 +
 11 files changed, 420 insertions(+), 6 deletions(-)

diff --git a/lib/librte_table/rte_table.h b/lib/librte_table/rte_table.h
index c13d40d..720514e 100644
--- a/lib/librte_table/rte_table.h
+++ b/lib/librte_table/rte_table.h
@@ -154,6 +154,77 @@ typedef int (*rte_table_op_entry_delete)(
void *entry);

 /**
+ * Lookup table entry add bulk
+ *
+ * @param table
+ *   Handle to lookup table instance
+ * @param key
+ *   Array containing lookup keys
+ * @param entries
+ *   Array containing data to be associated with each key. Every item in the
+ *   array has to point to a valid memory buffer where the first entry_size
+ *   bytes (table create parameter) are populated with the data.
+ * @param n_keys
+ *   Number of keys to add
+ * @param key_found
+ *   After successful invocation, key_found for every item in the array is set
+ *   to a value different than 0 if the current key is already present in the
+ *   table and to 0 if not. This pointer has to be set to a valid memory
+ *   location before the table entry add function is called.
+ * @param entries_ptr
+ *   After successful invocation, array *entries_ptr stores the handle to the
+ *   table entry containing the data associated with every key. This handle can
+ *   be used to perform further read-write accesses to this entry. This handle
+ *   is valid until the key is deleted from the table or the same key is
+ *   re-added to the table, typically to associate it with different data. This
+ *   pointer has to be set to a valid memory location before the function is
+ *   called.
+ * @return
+ *   0 on success, error code otherwise
+ */
+typedef int (*rte_table_op_entry_add_bulk)(
+   void *table,
+   void **keys,
+   void **entries,
+   uint32_t n_keys,
+   int *key_found,
+   void **entries_ptr);
+
+/**
+ * Lookup table entry delete bulk
+ *
+ * @param table
+ *   Handle to lookup table instance
+ * @param key
+ *   Array containing lookup keys
+ * @param n_keys
+ *   Number of keys to delete
+ * @param key_found
+ *   After successful invocation, key_found for every item in the array is set
+ *   to a value different than 0if the current key was present in the table
+ *   before the delete operation was performed and to 0 if not. This pointer
+ *   has to be set to a valid memory location before the table entry delete
+ *   function is called.
+ * @param entries
+ *   If entries pointer is NULL, this pointer is ignored for every entry found.
+ *   Else, after successful invocation, if specific key is found in the table
+ *   (key_found is different than 0 for this item after function call is
+ *   completed) and item of entry array points to a valid buffer (entry is set
+ *   to a value different than NULL before the function is called), then the
+ *   first entry_size bytes (table create parameter) in *entry store a copy of
+ *   table entry that contained the data associated with the current key before
+ *   the key was deleted.
+ * @return
+ *   0 on success, error code otherwise
+ */
+typedef int (*rte_table_op_entry_delete_bulk)(
+   void *table,
+   void **keys,
+   uint32_t n_keys,
+   int *key_found,
+   void **entries);
+
+/**
  * Lookup table lookup
  *
  * @param table
@@ -213,12 +284,14 @@ typedef int (*rte_table_op_stats_read)(

 /** Lookup table interface defining the lookup table operation */
 struct rte_table_ops {
-   rte_table_op_create f_create;   /**< Create */
-   rte_table_op_free f_free;   /**< Free */
-   rte_table_op_entry_add f_add;   /**< Entry add */
-   rte_table_op_entry_delete f_delete; /**< Entry delete */
-   rte_table_op_lookup f_lookup;   /**< Lookup */
-   rte_table_op_stats_read f_stats;/**< Stats */
+   rte_table_op_create f_create; /**< Create */
+   rte_table_op_free f_free; /**< Free */
+   rte_table_op_entry_add f_add; /**< Entry add */
+   rte_table_op_entry_delete f_delete;   /**< Entry delete */
+   rte_table_op_entry_add_bulk f_add_bulk;   /**< 

[dpdk-dev] [PATCH 0/4] pipeline: add bulk add/delete functions for table

[Maciej Gajdzica]

This patch adds bulk add/delete functions for tables used by pipelines. It
allows for adding/deleting many rules to pipeline tables in one function call.
It is particulary useful for firewall pipeline which is using ACL table. After
every add or delete, table is rebuild which leads to very long times when
trying to add/delete many entries.

Maciej Gajdzica (4):
  table: added bulk add/delete functions for table
  pipeline: added bulk add/delete functions for table
  test_table: added check for bulk add/delete to acl table unit test
  ip_pipeline: added cli commands for bulk add/delete to firewall
pipeline

 app/test/test_table_acl.c  |  166 
 examples/ip_pipeline/pipeline/pipeline_firewall.c  |  858 
 examples/ip_pipeline/pipeline/pipeline_firewall.h  |   14 +
 .../ip_pipeline/pipeline/pipeline_firewall_be.c|  157 
 .../ip_pipeline/pipeline/pipeline_firewall_be.h|   38 +
 lib/librte_pipeline/rte_pipeline.c |  106 +++
 lib/librte_pipeline/rte_pipeline.h |   62 ++
 lib/librte_table/rte_table.h   |   85 +-
 lib/librte_table/rte_table_acl.c   |  309 +++
 lib/librte_table/rte_table_array.c |2 +
 lib/librte_table/rte_table_hash_ext.c  |4 +
 lib/librte_table/rte_table_hash_key16.c|4 +
 lib/librte_table/rte_table_hash_key32.c|4 +
 lib/librte_table/rte_table_hash_key8.c |8 +
 lib/librte_table/rte_table_hash_lru.c  |4 +
 lib/librte_table/rte_table_lpm.c   |2 +
 lib/librte_table/rte_table_lpm_ipv6.c  |2 +
 lib/librte_table/rte_table_stub.c  |2 +
 18 files changed, 1821 insertions(+), 6 deletions(-)

-- 
1.7.9.5

[dpdk-dev] [PATCH v2 0/5] pipeline: add bulk add/delete functions for table

[Dumitrescu, Cristian]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Maciej Gajdzica
> Sent: Friday, September 11, 2015 1:32 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v2 0/5] pipeline: add bulk add/delete functions
> for table
> 
> This patch adds bulk add/delete functions for tables used by pipelines. It
> allows for adding/deleting many rules to pipeline tables in one function call.
> It is particulary useful for firewall pipeline which is using ACL table. After
> every add or delete, table is rebuild which leads to very long times when
> trying to add/delete many entries.
> 

Acked-by: Cristian Dumitrescu 

[dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1 for all NICs but 82598

[Matthew Hall]

On Fri, Sep 11, 2015 at 05:42:48PM +, Ananyev, Konstantin wrote:
> As I remember, with freebsd stack when TSO is on it was not unusual to see 
> chains of ~30 segments. 
> That's over port with 'normal' mtu (1.5K).
> Konstantin

This makes things quite tricky, because the TSO logic itself would need to 
handle the segment generation versus the limit, as the app would not really be 
able to force TSO to change its behavior, right?

Matthew.

[dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1 for all NICs but 82598

[Matthew Hall]

On Fri, Sep 11, 2015 at 07:18:20PM +0300, Vladislav Zolotarov wrote:
> We thought about linearization too. It's doable with extra mempool and it
> may be optional so that those that don't need could compile it out and/or
> disable it in a runtime...

High-level question. How realistic is sending a 40-segment frame in the first 
place? This whole thing seems kind of academic to me unless I missed 
something.

I usually use 2K pktmbufs and I don't think this is an uncommon size. Most 
jumbo frame hardware only does 9.5KB max frame size or so.

So I am having a hard time imagining how I'd end up with more than 10 segments 
as a worst-case scenario.

Matthew.

[dpdk-dev] [PATCH] igb_uio: use existing PCI macros

[Thomas Monjalon]

2015-09-10 20:33, Ferruh Yigit:
> > On Thu, Sep 10, 2015 at 6:01 PM, Ferruh Yigit 
> > wrote:
> > 
> > > To get pci_dev and vf number from dev, benefit from
> > > existing macros in pci.h
> > >
> > > Signed-off-by: Ferruh Yigit 
> > 
> > Correct me if I am wrong but you might need to provide wrappers for kernel
> > version <= 2.6.34 (or something that indicates availability of those).
> 
> Correct, those macros available after kernel version >= 2.6.34.
> If these is any chance that one using older kernel than this version,
> instead of having wrappers I am for keeping existing implementation and
> drop this patch.

Why should we support kernel older than 2.6.34?
Do we need to update doc/guides/rel_notes/supported_os.rst?

[dpdk-dev] [PATCH 2/2] enic: fix hash creation when not using first numa node

[David Marchand]

If dpdk is run with memory only available on socket != 0, then hash
creation will fail and flow director feature won't be available.
Fix this by asking for allocation on caller socket.

Signed-off-by: David Marchand 
---
 drivers/net/enic/enic_clsf.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/net/enic/enic_clsf.c b/drivers/net/enic/enic_clsf.c
index 656b25b..e7416ce 100644
--- a/drivers/net/enic/enic_clsf.c
+++ b/drivers/net/enic/enic_clsf.c
@@ -61,7 +61,6 @@
 #define DEFAULT_HASH_FUNC   rte_jhash
 #endif

-#define SOCKET_00
 #define ENICPMD_CLSF_HASH_ENTRIES   ENICPMD_FDIR_MAX

 void enic_fdir_stats_get(struct enic *enic, struct rte_eth_fdir_stats *stats)
@@ -247,7 +246,7 @@ int enic_clsf_init(struct enic *enic)
.key_len = sizeof(struct rte_eth_fdir_filter),
.hash_func = DEFAULT_HASH_FUNC,
.hash_func_init_val = 0,
-   .socket_id = SOCKET_0,
+   .socket_id = SOCKET_ID_ANY,
};

enic->fdir.hash = rte_hash_create(_params);
-- 
1.9.1

[dpdk-dev] [PATCH 1/2] enic: fix allocation when not using first numa node

[David Marchand]

Seen by code review.

If dpdk is run with memory only available on socket != 0, then enic pmd
refuses to initialize ports as this pmd requires some memory on socket 0.
Fix this by setting socket to SOCKET_ID_ANY, so that allocations happen on
the caller socket.

Signed-off-by: David Marchand 
---
 drivers/net/enic/enic_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/enic/enic_main.c b/drivers/net/enic/enic_main.c
index 3b8719f..46a90bd 100644
--- a/drivers/net/enic/enic_main.c
+++ b/drivers/net/enic/enic_main.c
@@ -539,7 +539,7 @@ enic_alloc_consistent(__rte_unused void *priv, size_t size,
*dma_handle = 0;

rz = rte_memzone_reserve_aligned((const char *)name,
-   size, 0, 0, ENIC_ALIGN);
+size, SOCKET_ID_ANY, 0, ENIC_ALIGN);
if (!rz) {
pr_err("%s : Failed to allocate memory requested for %s",
__func__, name);
-- 
1.9.1

[dpdk-dev] [PATCH] ixgbe: fix the wrong prompt for VF TSO

[Wenzhuo Lu]

When setting TSO on VF ixgbe NICs, for example, 82599, x550, the
prompt that TSO is not supported will be printed. But TSO is
supported by VF ixgbe NICs.
We should add TSO to the capability flag, so, we will not see the
wrong prompt.

Signed-off-by: Wenzhuo Lu 
---
 drivers/net/ixgbe/ixgbe_ethdev.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index b8ee1e9..23eeacc 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -2444,7 +2444,8 @@ ixgbevf_dev_info_get(struct rte_eth_dev *dev,
DEV_TX_OFFLOAD_IPV4_CKSUM  |
DEV_TX_OFFLOAD_UDP_CKSUM   |
DEV_TX_OFFLOAD_TCP_CKSUM   |
-   DEV_TX_OFFLOAD_SCTP_CKSUM;
+   DEV_TX_OFFLOAD_SCTP_CKSUM  |
+   DEV_TX_OFFLOAD_TCP_TSO;

dev_info->default_rxconf = (struct rte_eth_rxconf) {
.rx_thresh = {
-- 
1.9.3

[dpdk-dev] Compiling MLX4 Support into 2.1.0

[Nathan Speulda]

Thank you for the response,

I followed all of the documentation before I came to the forum on this
one.  OFED is installed and working correctly with all drivers loaded.  I
get to the point of compiling dpdk with support enabled and nothing appears
to come out during the compile (for mlx4 which is included in the
.config).  My interfaces are not being seen by the PMD though I am aware it
works differently than the base supported adapters.

Thanks,
Nathan

On Fri, Sep 11, 2015 at 9:35 AM, Adrien Mazarguil <
adrien.mazarguil at 6wind.com> wrote:

> Hi Nathan,
>
> On Fri, Sep 11, 2015 at 09:10:03AM -0700, Nathan Speulda wrote:
> > All,
> >
> > I am attempting to do some work using a CX3-Pro adapter in a forwarding
> > environment and am attempting to enable the supported PMD that is
> included
> > in the 2.1.0 release of DPDK.  My base distro is RHEL6.5 for stability
> > reasons.  Does anyone have a more detailed idea of how to get the
> Mellanox
> > PMD working correctly?  Does base distro have any impact on this at
> all?  I
> > have been unable to find what I need at the Mellanox community support.
>
> You need to install Mellanox OFED before attempting to compile the mlx4
> PMD, as described in the relevant documentation (doc/guides/nics/mlx4.rst)
> also available here:
>
>  http://dpdk.org/doc/guides/nics/mlx4.html
>
> See "Prerequisites" and "Getting Mellanox OFED" sections.
>
> It should work fine with all Linux distributions supported by Mellanox
> OFED. In your specific case, RHEL 6.5 is supported by MOFED 3.0-2.0.1.
>
> --
> Adrien Mazarguil
> 6WIND
>

[dpdk-dev] DPDK 2.2 roadmap

[Yuanhan Liu]

On Thu, Sep 10, 2015 at 09:55:18PM +0200, Thomas Monjalon wrote:
> 2015-09-10 15:27, Flavio Leitner:
> > On Thu, Sep 10, 2015 at 02:43:59PM +0200, Thomas Monjalon wrote:
> > > 2015-09-09 12:56, O'Driscoll, Tim:
> > > > Vhost Multi-Queue Support:  The vhost-user library will be updated to 
> > > > provide multi-queue support in the host similar to the RSS model so 
> > > > that guest driver may allocate multiple rx/tx queues which then may be 
> > > > used to load balance between cores. See 
> > > > http://dpdk.org/ml/archives/dev/2015-August/022758.html for more 
> > > > details.
> > > 
> > > Does it require a patch on Qemu?
> > 
> > Yes, it does. Last patchset seems to be v7.
> 
> It's better to wait the feature approved and integrated in Qemu first.

Agreed, and I'm working on it.

--yliu

[dpdk-dev] Compiling MLX4 Support into 2.1.0

[Nathan Speulda]

All,

I am attempting to do some work using a CX3-Pro adapter in a forwarding
environment and am attempting to enable the supported PMD that is included
in the 2.1.0 release of DPDK.  My base distro is RHEL6.5 for stability
reasons.  Does anyone have a more detailed idea of how to get the Mellanox
PMD working correctly?  Does base distro have any impact on this at all?  I
have been unable to find what I need at the Mellanox community support.

Thanks,
Nathan

[dpdk-dev] [PATCH] igb_uio: use existing PCI macros

[Mcnamara, John]

> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> Sent: Friday, September 11, 2015 9:11 AM
> To: dev at dpdk.org; Yigit, Ferruh; David Marchand
> Subject: Re: [dpdk-dev] [PATCH] igb_uio: use existing PCI macros
> 
> 2015-09-10 20:33, Ferruh Yigit:
> > > On Thu, Sep 10, 2015 at 6:01 PM, Ferruh Yigit
> > > 
> > > wrote:
> > >

> > Correct, those macros available after kernel version >= 2.6.34.
> > ...
> 
> Why should we support kernel older than 2.6.34?
> Do we need to update doc/guides/rel_notes/supported_os.rst?

If we do then  we should update he Linux Getting Started guide which says:

Required:

Kernel version >= 2.6.33

http://dpdk.org/doc/guides/linux_gsg/sys_reqs.html#system-software

And probably drop the section below itabout patching older kernels.

John.
-- 

[dpdk-dev] [PATCH 2/2] enic: fix hash creation when not using first numa node

[Sujith Sankar (ssujith)]

On 11/09/15 1:32 pm, "David Marchand"  wrote:

>If dpdk is run with memory only available on socket != 0, then hash
>creation will fail and flow director feature won't be available.
>Fix this by asking for allocation on caller socket.
>
>Signed-off-by: David Marchand 
>---
> drivers/net/enic/enic_clsf.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
>diff --git a/drivers/net/enic/enic_clsf.c b/drivers/net/enic/enic_clsf.c
>index 656b25b..e7416ce 100644
>--- a/drivers/net/enic/enic_clsf.c
>+++ b/drivers/net/enic/enic_clsf.c
>@@ -61,7 +61,6 @@
> #define DEFAULT_HASH_FUNC   rte_jhash
> #endif
> 
>-#define SOCKET_00
> #define ENICPMD_CLSF_HASH_ENTRIES   ENICPMD_FDIR_MAX
> 
> void enic_fdir_stats_get(struct enic *enic, struct rte_eth_fdir_stats
>*stats)
>@@ -247,7 +246,7 @@ int enic_clsf_init(struct enic *enic)
>   .key_len = sizeof(struct rte_eth_fdir_filter),
>   .hash_func = DEFAULT_HASH_FUNC,
>   .hash_func_init_val = 0,
>-  .socket_id = SOCKET_0,
>+  .socket_id = SOCKET_ID_ANY,
>   };
> 
>   enic->fdir.hash = rte_hash_create(_params);
>--

Acked by: Sujith Sankar 


> 
>1.9.1
>

[dpdk-dev] [PATCH 1/2] enic: fix allocation when not using first numa node

[Sujith Sankar (ssujith)]

On 11/09/15 1:32 pm, "David Marchand"  wrote:

>Seen by code review.
>
>If dpdk is run with memory only available on socket != 0, then enic pmd
>refuses to initialize ports as this pmd requires some memory on socket 0.
>Fix this by setting socket to SOCKET_ID_ANY, so that allocations happen on
>the caller socket.
>
>Signed-off-by: David Marchand 
>---
> drivers/net/enic/enic_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/net/enic/enic_main.c b/drivers/net/enic/enic_main.c
>index 3b8719f..46a90bd 100644
>--- a/drivers/net/enic/enic_main.c
>+++ b/drivers/net/enic/enic_main.c
>@@ -539,7 +539,7 @@ enic_alloc_consistent(__rte_unused void *priv, size_t
>size,
>   *dma_handle = 0;
> 
>   rz = rte_memzone_reserve_aligned((const char *)name,
>-  size, 0, 0, ENIC_ALIGN);
>+   size, SOCKET_ID_ANY, 0, ENIC_ALIGN);
>   if (!rz) {
>   pr_err("%s : Failed to allocate memory requested for %s",
>   __func__, name);
>--

Acked by: Sujith Sankar 

> 
>1.9.1
>

[dpdk-dev] DPDK 2.2 roadmap

[O'Driscoll, Tim]

> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Thursday, September 10, 2015 1:44 PM
> To: O'Driscoll, Tim
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] DPDK 2.2 roadmap
>
> 2015-09-09 12:56, O'Driscoll, Tim:
> > DCB for i40e :  DCB support will be extended to the i40e and X550
> NICs.
>
> A patch for DCB on X550 is already applied but the release notes part
> was forgotten.
>
> > IPsec Sample App:  A sample application will be provided to show how
> the
> > cryptodev library can be used to implement IPsec. This will be based
> on
> > the NetBSD IPsec implementation.
>
> For each API, it is really interesting to have some unit tests and some
> examples to show how it should be used. However adding an IPsec stack
> looks
> to be beyond the need of an API example. It may be big and difficult to
> maintain when updating DPDK.
> Why not spawn a new project here: http://dpdk.org/browse/ ?

What we're planning is a sample application that shows how hardware and 
software crypto accelerators can be used to accelerate a typical workload, 
which happens to be IPsec. We plan to provide an RFC next week which will give 
further details on what's being proposed. We don't expect maintenance to be a 
problem, but we can discuss that further when the scope has been clarified.

[dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh above 1 for all NICs but 82598

[Thomas Monjalon]

2015-09-11 17:47, Avi Kivity:
> On 09/11/2015 05:25 PM, didier.pallard wrote:
> > On 08/25/2015 08:52 PM, Vlad Zolotarov wrote:
> >>
> >> Helin, the issue has been seen on x540 devices. Pls., see a chapter 
> >> 7.2.1.1 of x540 devices spec:
> >>
> >> A packet (or multiple packets in transmit segmentation) can span any 
> >> number of
> >> buffers (and their descriptors) up to a limit of 40 minus WTHRESH 
> >> minus 2 (see
> >> Section 7.2.3.3 for Tx Ring details and section Section 7.2.3.5.1 for 
> >> WTHRESH
> >> details). For best performance it is recommended to minimize the 
> >> number of buffers
> >> as possible.
> >>
> >> Could u, pls., clarify why do u think that the maximum number of data 
> >> buffers is limited by 8?
> >>
> >> thanks,
> >> vlad
> >
> > Hi vlad,
> >
> > Documentation states that a packet (or multiple packets in transmit 
> > segmentation) can span any number of
> > buffers (and their descriptors) up to a limit of 40 minus WTHRESH 
> > minus 2.
> >
> > Shouldn't there be a test in transmit function that drops properly the 
> > mbufs with a too large number of
> > segments, while incrementing a statistic; otherwise transmit function 
> > may be locked by the faulty packet without
> > notification.
> >
> 
> What we proposed is that the pmd expose to dpdk, and dpdk expose to the 
> application, an mbuf check function.  This way applications that can 
> generate complex packets can verify that the device will be able to 
> process them, and applications that only generate simple mbufs can avoid 
> the overhead by not calling the function.

More than a check, it should be exposed as a capability of the port.
Anyway, if the application sends too much segments, the driver must
drop it to avoid hang, and maintain a dedicated statistic counter to allow
easy debugging.