On Mon, Jan 08, 2018 at 11:59:09AM +, Ferruh Yigit wrote:
> On 1/3/2018 2:12 PM, Andrew Rybchenko wrote:
> > On 01/03/2018 04:54 PM, Olivier Matz wrote:
> >> On Wed, Jan 03, 2018 at 02:43:59PM +0100, Olivier Matz wrote:
> >>> I've walked through the PMDs as suggested by Andrew, and there was
>
On 1/3/2018 2:12 PM, Andrew Rybchenko wrote:
> On 01/03/2018 04:54 PM, Olivier Matz wrote:
>> On Wed, Jan 03, 2018 at 02:43:59PM +0100, Olivier Matz wrote:
>>> I've walked through the PMDs as suggested by Andrew, and there was
>>> indeed some conflicts with the initial patch. I've just submitted th
On 01/03/2018 04:54 PM, Olivier Matz wrote:
On Wed, Jan 03, 2018 at 02:43:59PM +0100, Olivier Matz wrote:
I've walked through the PMDs as suggested by Andrew, and there was
indeed some conflicts with the initial patch. I've just submitted the
patch for vmxnet3 [1] and bnxt [2].
But there is sti
On Wed, Jan 03, 2018 at 02:43:59PM +0100, Olivier Matz wrote:
> I've walked through the PMDs as suggested by Andrew, and there was
> indeed some conflicts with the initial patch. I've just submitted the
> patch for vmxnet3 [1] and bnxt [2].
>
> But there is still an issue with the qede driver, tha
Hi,
On Wed, Dec 20, 2017 at 01:00:01PM +0300, Andrew Rybchenko wrote:
> On 12/19/2017 12:47 PM, Andrew Rybchenko wrote:
> > On 12/19/2017 12:29 PM, Olivier MATZ wrote:
> > > Hi,
> > >
> > > On Mon, Dec 18, 2017 at 02:38:55PM +0300, Andrew Rybchenko wrote:
> > > > On 12/18/2017 01:53 PM, Igor Ryzh
On 12/19/2017 12:47 PM, Andrew Rybchenko wrote:
On 12/19/2017 12:29 PM, Olivier MATZ wrote:
Hi,
On Mon, Dec 18, 2017 at 02:38:55PM +0300, Andrew Rybchenko wrote:
On 12/18/2017 01:53 PM, Igor Ryzhov wrote:
On Mon, Dec 18, 2017 at 1:35 PM, Andrew Rybchenko
mailto:arybche...@solarflare.com>> wro
On 12/19/2017 12:29 PM, Olivier MATZ wrote:
Hi,
On Mon, Dec 18, 2017 at 02:38:55PM +0300, Andrew Rybchenko wrote:
On 12/18/2017 01:53 PM, Igor Ryzhov wrote:
On Mon, Dec 18, 2017 at 1:35 PM, Andrew Rybchenko
mailto:arybche...@solarflare.com>> wrote:
On 12/14/2017 08:15 PM, Olivier Matz wr
Hi,
On Mon, Dec 18, 2017 at 02:38:55PM +0300, Andrew Rybchenko wrote:
> On 12/18/2017 01:53 PM, Igor Ryzhov wrote:
> >
> > On Mon, Dec 18, 2017 at 1:35 PM, Andrew Rybchenko
> > mailto:arybche...@solarflare.com>> wrote:
> >
> > On 12/14/2017 08:15 PM, Olivier Matz wrote:
> >
> > From
On 12/18/2017 01:53 PM, Igor Ryzhov wrote:
On Mon, Dec 18, 2017 at 1:35 PM, Andrew Rybchenko
mailto:arybche...@solarflare.com>> wrote:
On 12/14/2017 08:15 PM, Olivier Matz wrote:
From: Laurent Hardy mailto:laurent.ha...@6wind.com>>
When a new mac address is set, it is sa
Hello Andrew,
Don't you think that it's not correct that net/sfc works that way?
If we go further, dev->dev_ops->mac_addr_set not only should be called
before ether_addr_copy.
It should return status code, and in case of error ether_addr_copy
shouldn't be called at all.
Am I wrong?
Best regards,
On 12/14/2017 08:15 PM, Olivier Matz wrote:
From: Laurent Hardy
When a new mac address is set, it is saved in dev->data->mac_addrs
before the ethdev handler is called.
First, it is inconsistent with the other ethdev functions
rte_eth_dev_mac_addr_remove() and rte_eth_dev_mac_addr_add().
Moreo
11 matches
Mail list logo