() in order to get device
specific values.
And if the user doesn't care it should pass 0 as a queue length and this
case is also being taken care of on the rte_eth level.
Signed-off-by: Vlad Zolotarov
---
drivers/net/ena/ena_ethdev.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/dr
On 12/04/2017 12:54 PM, Ferruh Yigit wrote:
On 12/1/2017 6:22 PM, Vlad Zolotarov wrote:
On 12/01/2017 06:51 PM, Ferruh Yigit wrote:
On 12/1/2017 2:17 PM, Vlad Zolotarov wrote:
On 11/30/2017 09:29 PM, Ferruh Yigit wrote:
remove RTE_ETHDEV_HAS_LRO_SUPPORT flag from header.
Flag seems added
On 12/01/2017 06:51 PM, Ferruh Yigit wrote:
On 12/1/2017 2:17 PM, Vlad Zolotarov wrote:
On 11/30/2017 09:29 PM, Ferruh Yigit wrote:
remove RTE_ETHDEV_HAS_LRO_SUPPORT flag from header.
Flag seems added with the patch that adds LRO support, and intention
looks like giving a pointer to
resending after registering with the new email domain ;)
Please, see my comments below.
On 12/01/2017 05:17 PM, Vlad Zolotarov wrote:
On 11/30/2017 09:29 PM, Ferruh Yigit wrote:
remove RTE_ETHDEV_HAS_LRO_SUPPORT flag from header.
Flag seems added with the patch that adds LRO support, and
On 07/31/2016 10:46 AM, Vlad Zolotarov wrote:
>
>
> On 07/20/2016 05:24 PM, Tomasz Kulasek wrote:
>> This is an ABI deprecation notice for DPDK 16.11 in librte_ether about
>> changes in rte_eth_dev and rte_eth_desc_lim structures.
>>
>> In 16.11, we plan to int
t;l2_len = sizeof(struct ether_hdr);
>> bufs[i]->l3_len = sizeof(struct ipv4_hdr);
>> bufs[i]->l4_len = sizeof(struct tcp_hdr);
>> }
>>
>> /* Prepare burst of TX packets */
>> nb_prep = rte_eth_tx_prep(port, 0, bufs,
lds will be introduced in rte_eth_desc_lim: nb_seg_max and
> nb_mtu_seg_max, providing an information about max segments in TSO and
> non TSO packets acceptable by device.
>
> Signed-off-by: Tomasz Kulasek
Acked-by: Vlad Zolotarov
> ---
> doc/guides/rel_notes/deprecation.rst |7 +
On 11/29/15 11:10, Gleb Natapov wrote:
> On Sun, Nov 29, 2015 at 11:07:44AM +0200, Vlad Zolotarov wrote:
>>
>> On 11/26/15 22:35, Thomas Monjalon wrote:
>>> When introducing LRO, Vlad has defined the macro RTE_ETHDEV_HAS_LRO_SUPPORT:
>>> http://dpdk.org/br
On 11/26/15 22:35, Thomas Monjalon wrote:
> When introducing LRO, Vlad has defined the macro RTE_ETHDEV_HAS_LRO_SUPPORT:
> http://dpdk.org/browse/dpdk/commit/lib/librte_ether/rte_ethdev.h?id=8eecb329
>
> It allows to use the feature without version check (before the release or
> after a backport)
On 10/27/15 21:10, Ananyev, Konstantin wrote:
> Hi lads,
>
>> -Original Message-----
>> From: Vlad Zolotarov [mailto:vladz at cloudius-systems.com]
>> Sent: Tuesday, October 27, 2015 6:48 PM
>> To: Thomas Monjalon; Ananyev, Konstantin; Zhang, Helin
>> Cc:
On 10/27/15 20:09, Thomas Monjalon wrote:
> Any Follow-up to this discussion?
> Should we mark this patch as rejected?
Hmmm... This patch fixes an obvious spec violation. Why would it be
rejected?
>
> 2015-08-24 11:11, Vlad Zolotarov:
>> On 08/20/15 18:37, Vlad Zolotarov wr
On 10/23/15 11:32, Zhang, Helin wrote:
>
>> -Original Message-
>> From: Vlad Zolotarov [mailto:vladz at cloudius-systems.com]
>> Sent: Friday, October 23, 2015 4:27 PM
>> To: Zhang, Helin
>> Cc: Lu, Wenzhuo; dev at dpdk.org
>> Subject: Re: [dpdk-d
On 10/23/15 10:14, Zhang, Helin wrote:
>
> From: Vladislav Zolotarov [mailto:vladz at cloudius-systems.com]
> Sent: Friday, October 23, 2015 2:57 PM
> To: Zhang, Helin
> Cc: Lu, Wenzhuo; dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v4] ixgbe: Drop flow control frames from VFs
>
>
> On Oct 23,
On 10/08/15 05:17, Wu, Jingjing wrote:
>>> In SR-IOV mode a VF sending LFC or PFC would throttle the entire port.
>>> The workaround is to add a filter to drop pause frames from VFs from
>>> sending pause frames.
>> This is a very strange approach - this would silently disable the Tx FC
>> while
On 10/06/15 18:00, Michael S. Tsirkin wrote:
> On Tue, Oct 06, 2015 at 05:49:21PM +0300, Vlad Zolotarov wrote:
>>> and read/write the config space.
>>> This means that a single userspace bug is enough to corrupt kernel
>>> memory.
>> Could u, pls., provide and
On 10/06/15 16:58, Michael S. Tsirkin wrote:
> On Tue, Oct 06, 2015 at 11:23:11AM +0300, Vlad Zolotarov wrote:
>> Michael, how this or any other related patch is related to the problem u r
>> describing?
>> The above ability is there for years and if memory serves me
>&
On 10/06/15 01:49, Michael S. Tsirkin wrote:
> On Tue, Oct 06, 2015 at 01:09:55AM +0300, Vladislav Zolotarov wrote:
>> How about instead of trying to invent the wheel just go and attack the
>> problem
>> directly just like i've proposed already a few times in the last days:
>> instead
>> of lim
On 10/04/15 22:03, Greg KH wrote:
> On Sun, Oct 04, 2015 at 07:49:35PM +0300, Vlad Zolotarov wrote:
>> FYI: I've just posted to linux-kernel list patches that add support for both
>> MSI and MSI-X interrupt modes to uio_pci_generic driver.
>> It addresses most (all)
FYI: I've just posted to linux-kernel list patches that add support for
both MSI and MSI-X interrupt modes to uio_pci_generic driver.
It addresses most (all) remarks on this thread and also fixes some
issues this code has, e.g. not disabling msi-x in remove(), etc.
U are all welcome to comment..
On 10/01/15 17:47, Stephen Hemminger wrote:
> On Thu, 1 Oct 2015 11:00:28 +0300
> Vlad Zolotarov wrote:
>
>>
>> On 10/01/15 00:36, Stephen Hemminger wrote:
>>> On Wed, 30 Sep 2015 23:09:33 +0300
>>> Vlad Zolotarov wrote:
>>>
>>>> On
On 10/01/15 11:44, Michael S. Tsirkin wrote:
> On Wed, Sep 30, 2015 at 11:40:16PM +0300, Michael S. Tsirkin wrote:
>>> And for what, to prevent
>>> root from touching memory via dma that they can access in a million other
>>> ways?
>> So one can be reasonably sure a kernel oops is not a result of
On 10/01/15 00:36, Stephen Hemminger wrote:
> On Wed, 30 Sep 2015 23:09:33 +0300
> Vlad Zolotarov wrote:
>
>>
>> On 09/30/15 22:39, Michael S. Tsirkin wrote:
>>> On Wed, Sep 30, 2015 at 10:06:52PM +0300, Vlad Zolotarov wrote:
>>>>>> How w
On 10/01/15 00:36, Stephen Hemminger wrote:
> On Wed, 30 Sep 2015 23:09:33 +0300
> Vlad Zolotarov wrote:
>
>>
>> On 09/30/15 22:39, Michael S. Tsirkin wrote:
>>> On Wed, Sep 30, 2015 at 10:06:52PM +0300, Vlad Zolotarov wrote:
>>>>>> How w
On 09/30/15 22:39, Michael S. Tsirkin wrote:
> On Wed, Sep 30, 2015 at 10:06:52PM +0300, Vlad Zolotarov wrote:
>>>> How would iommu
>>>> virtualization change anything?
>>> Kernel can use an iommu to limit device access to memory of
>>> the contro
On 09/30/15 22:10, Vlad Zolotarov wrote:
>
>
> On 09/30/15 22:06, Vlad Zolotarov wrote:
>>
>>
>> On 09/30/15 21:55, Michael S. Tsirkin wrote:
>>> On Wed, Sep 30, 2015 at 09:15:56PM +0300, Vlad Zolotarov wrote:
>>>>
>>>> On 09/30/15 18
On 09/30/15 22:06, Vlad Zolotarov wrote:
>
>
> On 09/30/15 21:55, Michael S. Tsirkin wrote:
>> On Wed, Sep 30, 2015 at 09:15:56PM +0300, Vlad Zolotarov wrote:
>>>
>>> On 09/30/15 18:26, Michael S. Tsirkin wrote:
>>>> On Wed, Sep 30, 2015 at 03:50:09
On 09/30/15 21:55, Michael S. Tsirkin wrote:
> On Wed, Sep 30, 2015 at 09:15:56PM +0300, Vlad Zolotarov wrote:
>>
>> On 09/30/15 18:26, Michael S. Tsirkin wrote:
>>> On Wed, Sep 30, 2015 at 03:50:09PM +0300, Vlad Zolotarov wrote:
>>>> How not virtualizing io
On 09/30/15 18:26, Michael S. Tsirkin wrote:
> On Wed, Sep 30, 2015 at 03:50:09PM +0300, Vlad Zolotarov wrote:
>> How not virtualizing iommu forces "all or nothing" approach?
> Looks like you can't limit an assigned device to only access part of
> guest memory t
On 09/30/15 15:27, Michael S. Tsirkin wrote:
> On Wed, Sep 30, 2015 at 03:16:04PM +0300, Vlad Zolotarov wrote:
>>
>> On 09/30/15 15:03, Michael S. Tsirkin wrote:
>>> On Wed, Sep 30, 2015 at 02:53:19PM +0300, Vlad Zolotarov wrote:
>>>> On 09/30/15 14:41, Mi
On 09/30/15 15:03, Michael S. Tsirkin wrote:
> On Wed, Sep 30, 2015 at 02:53:19PM +0300, Vlad Zolotarov wrote:
>>
>> On 09/30/15 14:41, Michael S. Tsirkin wrote:
>>> On Wed, Sep 30, 2015 at 02:26:01PM +0300, Vlad Zolotarov wrote:
>>>> The whole idea is to bypa
On 09/30/15 14:41, Michael S. Tsirkin wrote:
> On Wed, Sep 30, 2015 at 02:26:01PM +0300, Vlad Zolotarov wrote:
>> The whole idea is to bypass kernel. Especially for networking...
> ... on dumb hardware that doesn't support doing that securely.
On a very capable HW that
On 09/30/15 13:58, Michael S. Tsirkin wrote:
> On Wed, Sep 30, 2015 at 01:37:22PM +0300, Vlad Zolotarov wrote:
>>
>> On 09/30/15 00:49, Michael S. Tsirkin wrote:
>>> On Tue, Sep 29, 2015 at 02:46:16PM -0700, Stephen Hemminger wrote:
>>>> On Tue, 29 Sep
On 09/30/15 00:49, Michael S. Tsirkin wrote:
> On Tue, Sep 29, 2015 at 02:46:16PM -0700, Stephen Hemminger wrote:
>> On Tue, 29 Sep 2015 23:54:54 +0300
>> "Michael S. Tsirkin" wrote:
>>
>>> On Tue, Sep 29, 2015 at 07:41:09PM +0300, Vlad Zolotarov wrot
On 09/27/15 12:43, Michael S. Tsirkin wrote:
> On Sun, Sep 27, 2015 at 10:05:11AM +0300, Vlad Zolotarov wrote:
>> Hi,
>> I was trying to use uio_pci_generic with Intel's 10G SR-IOV devices on
>> Amazon EC2 instances with Enhanced Networking enabled.
>> The idea
Hi,
I was trying to use uio_pci_generic with Intel's 10G SR-IOV devices on
Amazon EC2 instances with Enhanced Networking enabled.
The idea is to create a DPDK environment that doesn't require compiling
kernel modules (igb_uio).
However I was surprised to discover that uio_pci_generic refuses to w
On 09/13/15 14:47, Ananyev, Konstantin wrote:
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Avi Kivity
>> Sent: Friday, September 11, 2015 6:48 PM
>> To: Thomas Monjalon; Vladislav Zolotarov; didier.pallard
>> Cc: dev at dpdk.org
>> Subject: Re: [dpdk-
HW requires it regardless the presence of the VLAN tag in the received frame.
Otherwise Rx frames are being filtered out on the MTU-4 boundary.
Signed-off-by: Vlad Zolotarov
---
drivers/net/i40e/i40e_rxtx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/i40e
On 08/30/15 16:03, Vlad Zolotarov wrote:
> Hi, I have the most strange issue on a setup of 2 pairs of connected
> back to back XL710 cards.
> It seems that frames above 1510 bytes are being filtered out by an
> i40e PMD receiver.
> The same setup works perfectly when I use L
Hi, I have the most strange issue on a setup of 2 pairs of connected
back to back XL710 cards.
It seems that frames above 1510 bytes are being filtered out by an i40e
PMD receiver.
The same setup works perfectly when I use Linux drivers on both sides
but when I use a PMD on one side and a Linux
On 08/25/15 22:30, Vladislav Zolotarov wrote:
>
>
> On Aug 25, 2015 22:16, "Zhang, Helin" <mailto:helin.zhang at intel.com>> wrote:
> >
> >
> >
> > > -Original Message-
> > > From: Vlad Zolotarov [mailto:vladz at cloudius-s
tems.com>]
> > Sent: Tuesday, August 18, 2015 9:56 PM
> > To: Lu, Wenzhuo
> > Cc: dev at dpdk.org <mailto:dev at dpdk.org>; Zhang, Helin
> > Subject: RE: [dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs_thresh
> above 1 for all NICs but 82598
> >
> >
> >
>
On 08/24/15 20:51, Zhang, Helin wrote:
>
>> -Original Message-
>> From: Vlad Zolotarov [mailto:vladz at cloudius-systems.com]
>> Sent: Monday, August 24, 2015 4:14 AM
>> To: Zhang, Helin; Gleb Natapov; dev at dpdk.org
>> Subject: Re: [dpdk-dev] i40e and
On 08/24/15 14:13, Vlad Zolotarov wrote:
>
>
> On 03/05/15 07:56, Zhang, Helin wrote:
>> Hi Gleb
>>
>> Sorry for late! I am struggling on my tasks for the following DPDK
>> release these days.
>>
>>> -Original Message-
>>>
On 03/05/15 07:56, Zhang, Helin wrote:
> Hi Gleb
>
> Sorry for late! I am struggling on my tasks for the following DPDK release
> these days.
>
>> -Original Message-
>> From: Gleb Natapov [mailto:gleb at cloudius-systems.com]
>> Sent: Monday, March 2, 2015 8:56 PM
>> To: dev at dpdk.org
On 08/20/15 18:37, Vlad Zolotarov wrote:
> According to 82599 and x540 HW specifications RS bit *must* be
> set in the last descriptor of *every* packet.
>
> Before this patch there were 3 types of Tx callbacks that were setting
> RS bit every tx_rs_thresh descriptors. This pat
above, that will set the RS
bit in every EOP descriptor.
ixgbe_set_tx_function() will set the appropriate Tx callback according
to the device family.
This patch fixes the Tx hang we were constantly hitting with a
seastar-based application on x540 NIC.
Signed-off-by: Vlad Zolotarov
---
New in v4
above, that will set the RS
bit in every EOP descriptor.
ixgbe_set_tx_function() will set the appropriate Tx callback according
to the device family.
This patch fixes the Tx hang we were constantly hitting with a
seastar-based application on x540 NIC.
Signed-off-by: Vlad Zolotarov
---
New in v3
On 08/20/15 12:05, Vlad Zolotarov wrote:
>
>
> On 08/20/15 11:56, Vlad Zolotarov wrote:
>>
>>
>> On 08/20/15 11:41, Ananyev, Konstantin wrote:
>>> Hi Vlad,
>>>
>>>> -Original Message-
>>>> From: Vlad Zolotarov [mailto
On 08/20/15 11:56, Vlad Zolotarov wrote:
>
>
> On 08/20/15 11:41, Ananyev, Konstantin wrote:
>> Hi Vlad,
>>
>>> -Original Message-
>>> From: Vlad Zolotarov [mailto:vladz at cloudius-systems.com]
>>> Sent: Wednesday, August 19, 2015 11:03 AM
On 08/20/15 11:41, Ananyev, Konstantin wrote:
> Hi Vlad,
>
>> -Original Message-----
>> From: Vlad Zolotarov [mailto:vladz at cloudius-systems.com]
>> Sent: Wednesday, August 19, 2015 11:03 AM
>> To: Ananyev, Konstantin; Lu, Wenzhuo
>> Cc: dev at dpdk.org
S bit in each TXD (I still doubt we really
> do) - ,
Well, if u doubt u may ask the guys from the Intel networking division
that wrote the 82599 and x540 HW specs where they clearly state that. ;)
> I think inside PMD it still should be possible to check TX completion in
> chunk
According to 82599 and x540 HW specifications RS bit *must* be
set in the last descriptor of *every* packet.
This patch fixes the Tx hang we were constantly hitting with a
seastar-based application on x540 NIC.
Signed-off-by: Vlad Zolotarov
---
New in v2:
- ixgbevf: ixgbevf_dev_info_get
WTHRESH
different from zero.
>
> Regards,
> Helin
>
>> -Original Message-
>> From: Vlad Zolotarov [mailto:vladz at cloudius-systems.com]
>> Sent: Thursday, August 13, 2015 11:07 AM
>> To: dev at dpdk.org
>> Cc: Zhang, Helin; Ananyev, Konstantin; avi a
According to 82599 and x540 HW specifications RS bit *must* be
set in the last descriptor of *every* packet.
This patch fixes the Tx hang we were constantly hitting with a
seastar-based application on x540 NIC.
Signed-off-by: Vlad Zolotarov
---
drivers/net/ixgbe/ixgbe_ethdev.c | 9
On 07/30/15 20:33, Zhang, Helin wrote:
>
>> -Original Message-
>> From: Vlad Zolotarov [mailto:vladz at cloudius-systems.com]
>> Sent: Thursday, July 30, 2015 9:44 AM
>> To: Zhang, Helin; Ananyev, Konstantin
>> Cc: dev at dpdk.org
>> Su
On 07/30/15 20:01, Stephen Hemminger wrote:
> On Thu, 30 Jul 2015 19:50:27 +0300
> Vlad Zolotarov wrote:
>
>>
>> On 07/30/15 19:20, Avi Kivity wrote:
>>>
>>> On 07/30/2015 07:17 PM, Stephen Hemminger wrote:
>>>> On Thu, 30 Jul 2015 17:57
On 07/30/15 19:20, Avi Kivity wrote:
>
>
> On 07/30/2015 07:17 PM, Stephen Hemminger wrote:
>> On Thu, 30 Jul 2015 17:57:33 +0300
>> Vlad Zolotarov wrote:
>>
>>> Hi, Konstantin, Helin,
>>> there is a documented limitation of xl710 controllers (i40e d
On 07/30/15 19:10, Zhang, Helin wrote:
>
>> -Original Message-
>> From: Vlad Zolotarov [mailto:vladz at cloudius-systems.com]
>> Sent: Thursday, July 30, 2015 7:58 AM
>> To: dev at dpdk.org; Ananyev, Konstantin; Zhang, Helin
>> Subject: RFC: i40e
Hi, Konstantin, Helin,
there is a documented limitation of xl710 controllers (i40e driver)
which is not handled in any way by a DPDK driver.
From the datasheet chapter 8.4.1:
"? A single transmit packet may span up to 8 buffers (up to 8 data descriptors
per packet including
both the header and
TARTED(1) / STOPPED(0).
> */
> + lro : 1; /**< RX LRO is ON(1) / OFF(0) */
Acked-by: Vlad Zolotarov
> };
>
> /**
Simply initialze rx_pkt_burst callback to ixgbe_recv_pkts_lro_bulk_alloc() if
the conditions are right.
This is possible because work against HW in LRO and scattered cases is exactly
the same
and LRO callback already supports the bulk allocation.
Signed-off-by: Vlad Zolotarov
---
lib
always allocate sw_rsc_ring instead of explicitly allocating it in all possible
cases
when it may be needed: LRO and/or scattered Rx.
This will only impose sizeof(void*) * IXGBE_MAX_RING_DESC = 32KB overhead
per Rx queue as a price for a much simpler code, which seems reasonable.
Signed-off-by: Vlad
- ixgbe_rsc_entry -> ixgbe_scattered_rx_entry
- sw_rsc_ring -> sw_sc_ring
- ixgbe_free_rsc_cluster() -> ixgbe_free_sc_cluster()
- In local variables: xx_rsc_yy -> xx_sc_yy
Signed-off-by: Vlad Zolotarov
---
lib/librte_pmd_ixgbe/ixgbe
Signed-off-by: Vlad Zolotarov
---
lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 3 ---
lib/librte_pmd_ixgbe/ixgbe_rxtx.h | 1 -
2 files changed, 4 deletions(-)
diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
index 60344a9..a45f51e 100644
--- a/lib/librte_pmd_ixgbe
Move the above fields from ixgbe_hw to ixgbe_adapter.
Signed-off-by: Vlad Zolotarov
---
lib/librte_pmd_ixgbe/ixgbe/ixgbe_type.h | 2 --
lib/librte_pmd_ixgbe/ixgbe_ethdev.c | 8 +++
lib/librte_pmd_ixgbe/ixgbe_ethdev.h | 3 +++
lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 38
Rename RSC-specific structures to "Scattered Rx" derivatives.
- Always allocate Scattered Rx ring.
Vlad Zolotarov (5):
ixgbe: move rx_bulk_alloc_allowed and rx_vec_allowed to ixgbe_adapter
ixgbe: ixgbe_rx_queue: remove unused rsc_en field
ixgbe: Rename yy_rsc_xx -> yy
On 04/29/15 09:47, Vlad Zolotarov wrote:
>
>
> On 04/28/15 20:42, Ananyev, Konstantin wrote:
>> Hi Vlad,
>>
>>> -Original Message-
>>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Vlad Zolotarov
>>> Sent: Sunday, April 26,
On 04/28/15 20:42, Ananyev, Konstantin wrote:
> Hi Vlad,
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Vlad Zolotarov
>> Sent: Sunday, April 26, 2015 3:46 PM
>> To: dev at dpdk.org
>> Subject: [
Simply initialze rx_pkt_burst callback to ixgbe_recv_pkts_lro_bulk_alloc() if
the conditions are right.
This is possible because work against HW in LRO and scattered cases is exactly
the same
and LRO callback already supports the bulk allocation.
Signed-off-by: Vlad Zolotarov
---
lib
Kill ixgbe_recv_scattered_pkts() - use ixgbe_recv_pkts_lro_single_alloc()
instead.
Work against HW queues in LRO and scattered Rx cases is exactly the same.
Therefore we may drop the inferior callback.
Signed-off-by: Vlad Zolotarov
---
lib/librte_pmd_ixgbe/ixgbe_ethdev.c | 2 +-
lib
Signed-off-by: Vlad Zolotarov
---
lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 3 ---
lib/librte_pmd_ixgbe/ixgbe_rxtx.h | 1 -
2 files changed, 4 deletions(-)
diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
index 60344a9..a45f51e 100644
--- a/lib/librte_pmd_ixgbe
Move the above fields from ixgbe_hw to ixgbe_adapter.
Signed-off-by: Vlad Zolotarov
---
lib/librte_pmd_ixgbe/ixgbe/ixgbe_type.h | 2 --
lib/librte_pmd_ixgbe/ixgbe_ethdev.c | 8 +++
lib/librte_pmd_ixgbe/ixgbe_ethdev.h | 3 +++
lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 38
s
doesn't mean
to fix/add new functionality to it. VF PMD should be patched in the similar way
I've
patched PF PMD in my previous series in order to fix the same issues that were
fixed in
the PF PMD and in order to enable LRO and scattered Rx with bulk allocations.
Vlad Zolotaro
CC me when u send the series.
thanks,
vlad
>
> Regards,
> Helin
>
>> -----Original Message-
>> From: Vlad Zolotarov [mailto:vladz at cloudius-systems.com]
>> Sent: Wednesday, April 22, 2015 12:59 PM
>> To: Zhang, Helin; dev at dpdk.org
>> Cc: Ananyev
t; Though your code changes is good enough, but we may need to comply with what
> we did before. This will save our maintaining efforts in the future. Also we
> have similar rules for e1000, i40e, fm10k. Thank you very much!
>
> Regards,
> Helin
>
>> -----Original Messag
On 04/21/15 12:27, Bruce Richardson wrote:
> On Tue, Apr 21, 2015 at 11:51:40AM +0300, Vlad Zolotarov wrote:
>>
>> On 04/20/15 13:50, Bruce Richardson wrote:
>>> On Mon, Apr 20, 2015 at 01:07:59PM +0300, Vlad Zolotarov wrote:
>>>> Hi,
>>>> I w
On 04/20/15 13:50, Bruce Richardson wrote:
> On Mon, Apr 20, 2015 at 01:07:59PM +0300, Vlad Zolotarov wrote:
>> Hi,
>> I would like to ask if there is any reason why DPDK doesn't have support for
>> DCA feature?
>>
>> thanks,
>> vlad
> With modern
Hi,
I would like to ask if there is any reason why DPDK doesn't have support
for DCA feature?
thanks,
vlad
lon
> Tested-by: Thomas Monjalon
> Tested-by: John McNamara
Acked-by: Vlad Zolotarov
> ---
> changes in v2:
> - new patch
> changes in v3:
> - tested with clang and icc
>
> app/test/test_ring_perf.c | 2 +-
> lib/librte_pmd_e1000/em_ethdev.c
tialized" warning is another GCC bug which seems fixed
> in 4.7.
>
> Fixes: 8eecb3295aed ("ixgbe: add LRO support")
>
> Signed-off-by: Thomas Monjalon
Acked-by: Vlad Zolotarov
> ---
> changes in v2:
> - option -Wno-missing-field-initializers for old GCC instead
On 04/16/15 12:18, Thomas Monjalon wrote:
> 2015-04-16 12:14, Vlad Zolotarov:
>> On 04/15/15 23:49, Thomas Monjalon wrote:
>>> The "may be used uninitialized" warning seems to be another GCC bug and is
>>> workarounded with NULL initialization.
>&g
On 04/15/15 23:49, Thomas Monjalon wrote:
> With GCC 4.4.7 from CentOS 6.5, the following errors arise:
>
> lib/librte_pmd_ixgbe/ixgbe_rxtx.c: In function ?ixgbe_dev_rx_queue_setup?:
> lib/librte_pmd_ixgbe/ixgbe_rxtx.c:2509: error: missing initializer
> lib/librte_pmd_ixgbe/ixgbe_rxtx.c:2509: err
On 04/14/15 18:28, Thomas Monjalon wrote:
> 2015-04-14 18:21, Vlad Zolotarov:
>> On 04/14/15 18:13, Thomas Monjalon wrote:
>>> 2015-04-14 17:59, Vlad Zolotarov:
>>>> On 04/14/15 17:17, Thomas Monjalon wrote:
>>>>> 2015-04-14 16:38, Vlad Zolotarov:
On 04/14/15 18:13, Thomas Monjalon wrote:
> 2015-04-14 17:59, Vlad Zolotarov:
>> On 04/14/15 17:17, Thomas Monjalon wrote:
>>> 2015-04-14 16:38, Vlad Zolotarov:
>>>> On 04/14/15 16:06, Ananyev, Konstantin wrote:
>>>>> From: Vlad Zolotarov [mailto:vlad
On 04/14/15 17:53, Thomas Monjalon wrote:
> 2015-04-14 17:30, Vlad Zolotarov:
>> On 04/14/15 17:17, Thomas Monjalon wrote:
>>> 2015-04-14 16:38, Vlad Zolotarov:
>>>> On 04/14/15 16:06, Ananyev, Konstantin wrote:
>>>>> From: Vlad Zolotarov [mailto:vlad
On 04/14/15 17:17, Thomas Monjalon wrote:
> 2015-04-14 16:38, Vlad Zolotarov:
>> On 04/14/15 16:06, Ananyev, Konstantin wrote:
>>> From: Vlad Zolotarov [mailto:vladz at cloudius-systems.com]
>>>> On 04/14/15 12:31, Thomas Monjalon wrote:
>>>>
On 04/14/15 17:17, Thomas Monjalon wrote:
> 2015-04-14 16:38, Vlad Zolotarov:
>> On 04/14/15 16:06, Ananyev, Konstantin wrote:
>>> From: Vlad Zolotarov [mailto:vladz at cloudius-systems.com]
>>>> On 04/14/15 12:31, Thomas Monjalon wrote:
>>>>
On 04/14/15 16:23, Ananyev, Konstantin wrote:
>
>> -Original Message-
>> From: Vlad Zolotarov [mailto:vladz at cloudius-systems.com]
>> Sent: Tuesday, April 14, 2015 1:52 PM
>> To: Thomas Monjalon; Ananyev, Konstantin; Zhang, Helin
>> Cc: dev at dpdk.
On 04/14/15 16:06, Ananyev, Konstantin wrote:
>
>> -Original Message-
>> From: Vlad Zolotarov [mailto:vladz at cloudius-systems.com]
>> Sent: Tuesday, April 14, 2015 1:49 PM
>> To: Thomas Monjalon; Ananyev, Konstantin; Zhang, Helin
>> Cc: dev at dpdk.
On 04/14/15 12:31, Thomas Monjalon wrote:
> With GCC 4.4.7 from CentOS 6.5, the following errors arise:
>
> lib/librte_pmd_ixgbe/ixgbe_rxtx.c: In function ?ixgbe_dev_rx_queue_setup?:
> lib/librte_pmd_ixgbe/ixgbe_rxtx.c:2509: error: missing initializer
> lib/librte_pmd_ixgbe/ixgbe_rxtx.c:2509: err
On 04/14/15 12:31, Thomas Monjalon wrote:
> With GCC 4.4.7 from CentOS 6.5, the following errors arise:
>
> lib/librte_pmd_ixgbe/ixgbe_rxtx.c: In function ?ixgbe_dev_rx_queue_setup?:
> lib/librte_pmd_ixgbe/ixgbe_rxtx.c:2509: error: missing initializer
> lib/librte_pmd_ixgbe/ixgbe_rxtx.c:2509: err
On 03/31/15 14:47, Ananyev, Konstantin wrote:
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Vlad Zolotarov
>> Sent: Monday, March 30, 2015 8:21 PM
>> To: dev at dpdk.org
>> Subject: [dpdk-dev] [PATCH v9 0/3]: Add LR
On 03/31/15 13:25, Ananyev, Konstantin wrote:
>
>> -Original Message-
>> From: Vlad Zolotarov [mailto:vladz at cloudius-systems.com]
>> Sent: Monday, March 30, 2015 4:57 PM
>> To: Ananyev, Konstantin; dev at dpdk.org
>> Subject: Re: [dpdk-dev] [PAT
ixgbe_rx_queue.
- Use the appropriate handler when LRO is requested.
Signed-off-by: Vlad Zolotarov
---
New in v9:
- Move new IXGBE_XXX macros to ixgbe_ethdev.h
New in v8:
- Took the RSC configuration code from ixgbe_dev_rx_init() into a separate
function - ixgbe_set_rsc
cluster's HEAD buffer into
the inline function.
Signed-off-by: Vlad Zolotarov
---
New in v8:
- Fixed the structs naming: igb_xxx -> ixgbe_xxx
- Adjust a code style with the ixgbe PMD styling.
New in v3:
- ixgbe_rx_alloc_bufs(): Always reset refcnt of the buffers to 1.
- Removed the not needed casting.
- ixgbe_dev_rx_init(): shorten the lines by defining a local alias variable
to access
&dev->data->dev_conf.rxmode.
Signed-off-by: Vlad Zolotarov
---
New in v6:
- Fixed a compilation error caused by a patches rec
Removed rte_eth_dev_data.lro_bulk_alloc and added
ixgbe_hw.rx_bulk_alloc_allowed
instead.
- Unified the rx_pkt_bulk callback setting (a separate new patch).
- Fixed a few styling and spelling issues.
Vlad Zolotarov (3):
ixgbe: Cleanups
ixgbe: Code refactoring
ixgbe: Add
On 03/30/15 18:37, Vlad Zolotarov wrote:
>
>
> On 03/30/15 17:18, Ananyev, Konstantin wrote:
>> Hi Vlad,
>>
>>> -Original Message-
>>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Vlad Zolotarov
>>> Sent: Wednesday, March 18,
On 03/30/15 17:18, Ananyev, Konstantin wrote:
> Hi Vlad,
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Vlad Zolotarov
>> Sent: Wednesday, March 18, 2015 5:52 PM
>> To: dev at dpdk.org
>> Subject: [dpdk-dev] [
On 03/18/15 19:52, Vlad Zolotarov wrote:
> This series adds the missing flow for enabling the LRO in the ethdev and
> adds a support for this feature in the ixgbe PMD. There is a big hope that
> this
> initiative is going to be picked up by some Intel developer that would add
>
1 - 100 of 254 matches
Mail list logo
