* Re: [PATCH 5/6] [v4] phylib: Support attaching to generic 10g driver
From: David Miller @ 2014-01-07 5:56 UTC (permalink / raw)
To: shh.xie
Cc: jg1.han, mugunthanvnm, f.fainelli, netdev, linux-kernel,
Shaohui.Xie, afleming
In-Reply-To: <1389060865-7143-1-git-send-email-shh.xie@gmail.com>
From: <shh.xie@gmail.com>
Date: Tue, 7 Jan 2014 10:14:25 +0800
> -static int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
> +int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
> u32 flags, phy_interface_t interface)
Since you are changing where the open parenthesis is, you must reindent
the arguments on the second line so that they start exactly at the
first column after that openning parenthesis.
^ permalink raw reply
* Re: [PATCH net 1/2] macvlan: forbid L2 fowarding offload for macvtap
From: David Miller @ 2014-01-07 5:57 UTC (permalink / raw)
To: jasowang; +Cc: netdev, linux-kernel, mst, john.r.fastabend, nhorman
In-Reply-To: <52CB71B2.4070005@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Tue, 07 Jan 2014 11:17:06 +0800
> On 01/07/2014 04:47 AM, David Miller wrote:
>> From: Jason Wang <jasowang@redhat.com>
>> Date: Mon, 6 Jan 2014 11:21:06 +0800
>>
>>> L2 fowarding offload will bypass the rx handler of real device. This will make
>>> the packet could not be forwarded to macvtap device. Another problem is the
>>> dev_hard_start_xmit() called for macvtap does not have any synchronization.
>>>
>>> Fix this by forbidding L2 forwarding for macvtap.
>>>
>>> Cc: John Fastabend <john.r.fastabend@intel.com>
>>> Cc: Neil Horman <nhorman@tuxdriver.com>
>>> Signed-off-by: Jason Wang <jasowang@redhat.com>
>> I think I agree with Neil that the rx_handler change might be the best
>> way to fix this. That change seems to have a lot of nice unintended
>> side effects, no?
>
> Not all sides effects are nice.
>
> One obvious issue is it disables the multiqueue macvtap transmission,
> since all queues will contend on a single qdisc lock of macvlan. And
> even more, multiqueue macvtap support creating and destroying a queue on
> demand which is not supported by L2 forwarding offload.
>
> So L2 forwarding offload needs more fixes to let the multiqueue macvtap
> works. Currently, we really need this patch to make sure macvtap works
> as expected.
Ok I moved these two patches back to "Under Review".
These are pretty last minute and we'll need to make a decision on
what to do before Friday if you want these changes to really make
it into 3.13
^ permalink raw reply
* Re: [PATCH net 1/2] macvlan: forbid L2 fowarding offload for macvtap
From: Jason Wang @ 2014-01-07 6:22 UTC (permalink / raw)
To: John Fastabend
Cc: Neil Horman, davem, netdev, linux-kernel, mst, John Fastabend,
Vlad Yasevich
In-Reply-To: <52CB8D54.9090506@gmail.com>
On 01/07/2014 01:15 PM, John Fastabend wrote:
> On 01/06/2014 07:10 PM, Jason Wang wrote:
>> On 01/06/2014 08:26 PM, Neil Horman wrote:
>>> On Mon, Jan 06, 2014 at 03:54:21PM +0800, Jason Wang wrote:
>>>> On 01/06/2014 03:35 PM, John Fastabend wrote:
>>>>> On 01/05/2014 07:21 PM, Jason Wang wrote:
>>>>>> L2 fowarding offload will bypass the rx handler of real device. This
>>>>>> will make
>>>>>> the packet could not be forwarded to macvtap device. Another problem
>>>>>> is the
>>>>>> dev_hard_start_xmit() called for macvtap does not have any
>>>>>> synchronization.
>>>>>>
>>>>>> Fix this by forbidding L2 forwarding for macvtap.
>>>>>>
>>>>>> Cc: John Fastabend <john.r.fastabend@intel.com>
>>>>>> Cc: Neil Horman <nhorman@tuxdriver.com>
>>>>>> Signed-off-by: Jason Wang <jasowang@redhat.com>
>>>>>> ---
>>>>>> drivers/net/macvlan.c | 5 ++++-
>>>>>> 1 files changed, 4 insertions(+), 1 deletions(-)
>>>>>>
>>>>> I must be missing something.
>>>>>
>>>>> The lower layer device should set skb->dev to the correct macvtap
>>>>> device on receive so that in netif_receive_skb_core() the macvtap
>>>>> handler is hit. Skipping the macvlan receive handler should be OK
>>>>> because the switching was done by the hardware. If I read macvtap.c
>>>>> correctly macvlan_common_newlink() is called with 'dev' where 'dev'
>>>>> is the macvtap device. Any idea what I'm missing? I guess I'll need
>>>>> to setup a macvtap test case.
>>>> Unlike macvlan, macvtap depends on rx handler on the lower device to
>>>> work. In this case macvlan_handle_frame() will call macvtap_receive().
>>>> So doing netif_receive_skb_core() for macvtap device directly won't
>>>> work
>>>> since we need to forward the packet to userspace instead of kernel.
>>>>
>>>> For net-next.git, it may work since commit
>>>> 6acf54f1cf0a6747bac9fea26f34cfc5a9029523 let macvtap device
>>>> register an
>>>> rx handler for itself.
>>> I agree, this seems like it should already be fixed with the above
>>> commit. With
>>> this the macvlan rx handler should effectively be a no-op as far as the
>>> reception of frames is concerned. As long as the driver sets the
>>> dev correctly
>>> to the macvtap device (and it appears to), macvtap will get frames
>>> to user
>>> space, regardless of weather the software or hardware did the
>>> switching. If
>>> thats the case though, I think the solution is moving that fix to
>>> -stable
>>> (pending testing of course), rather than comming up with a new fix.
>>>
>>>>> And what synchronization are you worried about on
>>>>> dev_hard_start_xmit()?
>>>>> In the L2 forwarding offload case macvlan_open() clears the
>>>>> NETIF_F_LLTX
>>>>> flag so HARD_TX_LOCK protects the driver txq. We might hit this
>>>>> warning
>>>>> in dev_queue_xmit() though,
>>>>>
>>>>> net_crit_ratelimited("Virtual device %s asks to queue packet!\n",
>>>>>
>>>>> Perhaps we can remove it.
>>>> The problem is macvtap does not call dev_queue_xmit() for macvlan
>>>> device. It calls macvlan_start_xmit() directly from
>>>> macvtap_get_user().
>>>> So HARD_TX_LOCK was not done for the txq.
>>> This seems to also be fixed by
>>> 6acf54f1cf0a6747bac9fea26f34cfc5a9029523.
>>> Macvtap does, as of that commit use dev_queue_xmit for the
>>> transmission of
>>> frames to the lowerdevice.
>>
>> Unfortunately not. This commit has a side effect that it in fact
>> disables the multiqueue macvtap transmission. Since all macvtap queues
>> will contend on a single qdisc lock.
>>
>
> They will only contend on a single qdisc lock if the lower device has
> 1 queue.
I think we are talking about 6acf54f1cf0a6747bac9fea26f34cfc5a9029523.
The qdisc or txq lock were macvlan device itself since dev_queue_xmit()
was called for macvlan device itself. So even if lower device has
multiple txqs, if you just create a one queue macvlan device, you will
get lock contention on macvlan device. And even if you explicitly
specifying the txq numbers ( though I don't believe most management
software will do this) when creating the macvlan/macvtap device, you
must also configure the XPS for macvlan to make sure it has the
possibility of using multiple transmit queues.
> Perhaps defaulting the L2 forwarding devices to 1queue was a
> mistake. But the same issue arises when running macvtap over a
> non-multiqueue nic. Or even if you have a multiqueue device and create
> many more macvtap queues than the lower device has queues.
>
> Shouldn't the macvtap configuration take into account the lowest level
> devices queues?
See commit 8ffab51b3dfc54876f145f15b351c41f3f703195 ("macvlan: lockless
tx path"). It allows the management to create a device without worrying
the underlying device.
> How does using the L2 forwarding device change the
> contention issues? Without the L2 forwarding LLTX is enabled but the
> qdisc lock, etc is still acquired on the device below the macvlan.
>
That's the point. We need make sure the txq selection and qdisc lock
were done for the lower device not for the macvlan device itself. Then
macvlan can automatically benefit from the multi-queue capable lower
devices. But L2 forwarding needs to contend on the txq lock on macvlan
device itself, which is unnecessary and can complex the management.
> The ixgbe driver as it is currently written can be configured for up to
> 4 queues by setting numtxqueues when the device is created. I assume
> when creating macvtap queues the user needs to account for the number
> of queues supported by the lower device.
>
We'd better not complicate the task of management, lockless tx path work
very well so we can just keep it. Btw, there's no way for the user to
know the maximum number of queues that L2 forwarding supports.
>> For L2 forwarding offload itself, more issues need to be addressed for
>> multiqueue macvtap:
>>
>> - ndo_dfwd_add_station() can only create queues per device at ndo_open,
>> but multiqueue macvtap allows user to create and destroy queues at their
>> will and at any time.
>
> same argument as above, isn't this the same when running macvtap without
> the l2 offloads over a real device? I expect you hit the same contention
> points when running over a real device.
Not true and not only for contention.
Macvtap allows user to create or destroy a queue by simply open or close
to character device /dev/tapX. But currently, we do nothing when a new
queue was created or destroyed for L2 forwarding offload.
For contention, lockless tx path make the contention only happens for
the txq or qdisc for the lower device, but L2 forwarding offload make
contention also happen for the macvlan device itself.
>
>
>> - it looks that ixgbe has a upper limit of 4 queues per station, but
>> macvtap currently allows up to 16 queues per device.
>>
>
> The 4 limit was to simplify the code because the queue mapping in the
> driver gets complicated if it is greater than 4. We can probably
> increase this latter. But sorry reiterating how is this different than
> a macvtap on a real device that supports a max of 4 queues?
Well, it maybe easy. I just point out possible issues we may meet currently.
>
>> So more works need to be done and unless those above 3 issues were
>> addressed, this patch is really needed to make sure macvtap works.
>>
>
> Agreed there is a lot more work here to improve things I'm just not
> sure we need to disable this now. Also note its the l2 forwarding
> should be disabled by default so a user would have to enable the
> feature flag.
Even if it was disabled by default. We should not surprise the user who
want to enable it for macvtap.
>
> Thanks,
> John
>
Thanks
^ permalink raw reply
* [PATCH net-next 0/2] Pack struct xfrm_usersa_info and struct xfrm_userpolicy_info
From: Fan Du @ 2014-01-07 6:48 UTC (permalink / raw)
To: steffen.klassert; +Cc: stephen, netdev, davem, dev
When trying to setup IPsec configuration on a 64bits host with
iproute2(32bits compiled), the intened xfrm policy and sa is
either deficit or wrong when kernel trying to parse user land
information.
Further investigatino shows that:
L: kernel
R: iproute2
sizeof userpolicy usersa
64bits(unpacked) 168/168 224/224
32bits(unpacked) 164/164 220/220
^ ^
L R
To keep kernel and user land see a consistent structure, after
add packing attribute, now it looks like this:
64bits( packed) 164/164 217/217
32bits( packed) 164/164 217/217
^ ^
L R
Then different kernel/iproute2 build configuration will not impact IPsec setup.
Fan Du (2):
include/uapi/linux/xfrm.h: Pack struct xfrm_userpolicy_info
include/uapi/linux/xfrm.h: Pack struct xfrm_usersa_info
include/uapi/linux/xfrm.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH net-next 1/2] include/uapi/linux/xfrm.h: Pack struct xfrm_userpolicy_info
From: Fan Du @ 2014-01-07 6:48 UTC (permalink / raw)
To: steffen.klassert; +Cc: stephen, netdev, davem, dev
In-Reply-To: <1389077339-12814-1-git-send-email-fan.du@windriver.com>
Otherwise 64bits kernel has sizeof(struct xfrm_userpolicy_info) 168 bytes,
while 32bits compiled iproute2 see the same structure as 164 bytes, which
leading deficit xfrm policy, in turn broken IPsec connectivity.
Fix this by packing the structure.
Signed-off-by: Fan Du <fan.du@windriver.com>
---
include/uapi/linux/xfrm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/linux/xfrm.h b/include/uapi/linux/xfrm.h
index a8cd6a4..470bfae 100644
--- a/include/uapi/linux/xfrm.h
+++ b/include/uapi/linux/xfrm.h
@@ -405,7 +405,7 @@ struct xfrm_userpolicy_info {
/* Automatically expand selector to include matching ICMP payloads. */
#define XFRM_POLICY_ICMP 2
__u8 share;
-};
+} __attribute__((packed));
struct xfrm_userpolicy_id {
struct xfrm_selector sel;
--
1.7.9.5
^ permalink raw reply related
* [PATCH net-next 2/2] include/uapi/linux/xfrm.h: Pack struct xfrm_usersa_info
From: Fan Du @ 2014-01-07 6:48 UTC (permalink / raw)
To: steffen.klassert; +Cc: davem, stephen, dev, netdev
In-Reply-To: <1389077339-12814-1-git-send-email-fan.du@windriver.com>
Otherwise 64bits kernel has sizeof(struct xfrm_usersa_info) 224 bytes,
while 32bits compiled iproute2 see the same structure as 220 bytes, which
leading deficit xfrm sa, in turn broken IPsec connectivity.
Fix this by packing the structure.
Signed-off-by: Fan Du <fan.du@windriver.com>
---
include/uapi/linux/xfrm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/linux/xfrm.h b/include/uapi/linux/xfrm.h
index 470bfae..61460c4 100644
--- a/include/uapi/linux/xfrm.h
+++ b/include/uapi/linux/xfrm.h
@@ -366,7 +366,7 @@ struct xfrm_usersa_info {
#define XFRM_STATE_AF_UNSPEC 32
#define XFRM_STATE_ALIGN4 64
#define XFRM_STATE_ESN 128
-};
+} __attribute__((packed));
#define XFRM_SA_XFLAG_DONT_ENCAP_DSCP 1
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH net-next 0/2] Pack struct xfrm_usersa_info and struct xfrm_userpolicy_info
From: Fan Du @ 2014-01-07 6:55 UTC (permalink / raw)
To: steffen.klassert; +Cc: stephen, netdev, davem, dev
In-Reply-To: <1389077339-12814-1-git-send-email-fan.du@windriver.com>
Oh, I don't know why '[strongSwan-dev]' is tagged in front of subject for only part of whole patch set.
In fact, I didn't mean to add '[strongSwan-dev]' into subject line. Sorry for the inconvenience.
On 2014年01月07日 14:48, Fan Du wrote:
> When trying to setup IPsec configuration on a 64bits host with
> iproute2(32bits compiled), the intened xfrm policy and sa is
> either deficit or wrong when kernel trying to parse user land
> information.
>
> Further investigatino shows that:
> L: kernel
> R: iproute2
>
> sizeof userpolicy usersa
> 64bits(unpacked) 168/168 224/224
> 32bits(unpacked) 164/164 220/220
> ^ ^
> L R
>
> To keep kernel and user land see a consistent structure, after
> add packing attribute, now it looks like this:
>
> 64bits( packed) 164/164 217/217
> 32bits( packed) 164/164 217/217
> ^ ^
> L R
>
> Then different kernel/iproute2 build configuration will not impact IPsec setup.
>
> Fan Du (2):
> include/uapi/linux/xfrm.h: Pack struct xfrm_userpolicy_info
> include/uapi/linux/xfrm.h: Pack struct xfrm_usersa_info
>
> include/uapi/linux/xfrm.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
--
浮沉随浪只记今朝笑
--fan
_______________________________________________
Dev mailing list
Dev@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/dev
^ permalink raw reply
* RE: [PATCH 5/6] [v4] phylib: Support attaching to generic 10g driver
From: Shaohui Xie @ 2014-01-07 7:04 UTC (permalink / raw)
To: David Miller, shh.xie@gmail.com
Cc: jg1.han@samsung.com, mugunthanvnm@ti.com, f.fainelli@gmail.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
afleming@gmail.com
In-Reply-To: <20140107.005607.716747884959539511.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Tuesday, January 07, 2014 1:56 PM
> To: shh.xie@gmail.com
> Cc: jg1.han@samsung.com; mugunthanvnm@ti.com; f.fainelli@gmail.com;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Xie Shaohui-B21989;
> afleming@gmail.com
> Subject: Re: [PATCH 5/6] [v4] phylib: Support attaching to generic 10g
> driver
>
> From: <shh.xie@gmail.com>
> Date: Tue, 7 Jan 2014 10:14:25 +0800
>
> > -static int phy_attach_direct(struct net_device *dev, struct
> > phy_device *phydev,
> > +int phy_attach_direct(struct net_device *dev, struct phy_device
> > +*phydev,
> > u32 flags, phy_interface_t interface)
>
> Since you are changing where the open parenthesis is, you must reindent
> the arguments on the second line so that they start exactly at the first
> column after that openning parenthesis.
>
[S.H] OK. Thank you!
Will fix it in next version.
Best Regards,
Shaohui Xie
^ permalink raw reply
* Re: [PATCH net 1/2] macvlan: forbid L2 fowarding offload for macvtap
From: John Fastabend @ 2014-01-07 7:26 UTC (permalink / raw)
To: Jason Wang
Cc: John Fastabend, Neil Horman, davem, netdev, linux-kernel, mst,
Vlad Yasevich
In-Reply-To: <52CB9D1A.1050101@redhat.com>
[...]
>>> Unfortunately not. This commit has a side effect that it in fact
>>> disables the multiqueue macvtap transmission. Since all macvtap queues
>>> will contend on a single qdisc lock.
>>>
>>
>> They will only contend on a single qdisc lock if the lower device has
>> 1 queue.
>
> I think we are talking about 6acf54f1cf0a6747bac9fea26f34cfc5a9029523.
Yes.
>
> The qdisc or txq lock were macvlan device itself since dev_queue_xmit()
> was called for macvlan device itself. So even if lower device has
> multiple txqs, if you just create a one queue macvlan device, you will
> get lock contention on macvlan device. And even if you explicitly
> specifying the txq numbers ( though I don't believe most management
> software will do this) when creating the macvlan/macvtap device, you
> must also configure the XPS for macvlan to make sure it has the
> possibility of using multiple transmit queues.
>
OK I think I'm finally putting all the pieces together thanks.
Do you know why macvtap is setting dev->tx_queue_len by default? If you
zero this then the noqueue_qdisc is used and the q->enqueue check in
dev_queue_xmit will fail.
Also if XPS is not configured then skb_tx_hash is used so multiple
transmit queues will still be used.
>> Perhaps defaulting the L2 forwarding devices to 1queue was a
>> mistake. But the same issue arises when running macvtap over a
>> non-multiqueue nic. Or even if you have a multiqueue device and create
>> many more macvtap queues than the lower device has queues.
>>
>> Shouldn't the macvtap configuration take into account the lowest level
>> devices queues?
>
> See commit 8ffab51b3dfc54876f145f15b351c41f3f703195 ("macvlan: lockless
> tx path"). It allows the management to create a device without worrying
> the underlying device.
OK.
>> How does using the L2 forwarding device change the
>> contention issues? Without the L2 forwarding LLTX is enabled but the
>> qdisc lock, etc is still acquired on the device below the macvlan.
>>
>
> That's the point. We need make sure the txq selection and qdisc lock
> were done for the lower device not for the macvlan device itself. Then
> macvlan can automatically benefit from the multi-queue capable lower
> devices. But L2 forwarding needs to contend on the txq lock on macvlan
> device itself, which is unnecessary and can complex the management.
If I make the l2 forwarding defaults a bit better then using the L2
forwarding case should not be any more complex. And because the queues
are dedicated to the macvtap device any contention from qdisc lock, etc
comes from the upper device only. Also if I get the bandwidth controls
in we can set the max/min bandwidth per macvtap device this way. That
is future work though.
>> The ixgbe driver as it is currently written can be configured for up to
>> 4 queues by setting numtxqueues when the device is created. I assume
>> when creating macvtap queues the user needs to account for the number
>> of queues supported by the lower device.
>>
>
> We'd better not complicate the task of management, lockless tx path work
> very well so we can just keep it. Btw, there's no way for the user to
> know the maximum number of queues that L2 forwarding supports.
Good point I'll add an attribute to query it.
>>> For L2 forwarding offload itself, more issues need to be addressed for
>>> multiqueue macvtap:
>>>
>>> - ndo_dfwd_add_station() can only create queues per device at ndo_open,
>>> but multiqueue macvtap allows user to create and destroy queues at their
>>> will and at any time.
>>
>> same argument as above, isn't this the same when running macvtap without
>> the l2 offloads over a real device? I expect you hit the same contention
>> points when running over a real device.
>
> Not true and not only for contention.
>
> Macvtap allows user to create or destroy a queue by simply open or close
> to character device /dev/tapX. But currently, we do nothing when a new
> queue was created or destroyed for L2 forwarding offload.
>
> For contention, lockless tx path make the contention only happens for
> the txq or qdisc for the lower device, but L2 forwarding offload make
> contention also happen for the macvlan device itself.
Right, but there will be less contention there because those queues
are a dedicated resource for the upper device.
At this point I think I need to put together a real testbed and
benchmark some of this with netperf and perf running to get real
numbers. When I originally did the l2 forwarding I did not do any
testing with multiple macvtap queues and only very limited work with
macvtap.
>
>>
>>
>>> - it looks that ixgbe has a upper limit of 4 queues per station, but
>>> macvtap currently allows up to 16 queues per device.
>>>
>>
>> The 4 limit was to simplify the code because the queue mapping in the
>> driver gets complicated if it is greater than 4. We can probably
>> increase this latter. But sorry reiterating how is this different than
>> a macvtap on a real device that supports a max of 4 queues?
>
> Well, it maybe easy. I just point out possible issues we may meet currently.
Right.
>>
>>> So more works need to be done and unless those above 3 issues were
>>> addressed, this patch is really needed to make sure macvtap works.
>>>
>>
>> Agreed there is a lot more work here to improve things I'm just not
>> sure we need to disable this now. Also note its the l2 forwarding
>> should be disabled by default so a user would have to enable the
>> feature flag.
>
> Even if it was disabled by default. We should not surprise the user who
> want to enable it for macvtap.
So the question is what to do in net while we improve net-next. Either
we fix the crash from the null txq and note that with l2 forwarding
some non default configuration is needed for optimal performance OR
for now disable it as your patch does. I would prefer to fix the crash
and note the configuration but I see your point about surprising users
so could go either way.
Neil any thoughts?
To fix the null txq in the gso case adding a check for a non-null
txq before calling txq_trans_update() makes sense to me. We already
have the check in the non-gso case so making it symmetric fixes it.
>>
>> Thanks,
>> John
>>
>
> Thanks
>
^ permalink raw reply
* [PATCH] ipv6: pcpu_tstats.syncp should be initialised in ip6_vti.c
From: roy.qing.li @ 2014-01-07 7:39 UTC (permalink / raw)
To: netdev; +Cc: fengguang.wu
In-Reply-To: <20140105022017.GB16180@localhost>
From: Li RongQing <roy.qing.li@gmail.com>
initialise pcpu_tstats.syncp to kill the calltrace
[ 11.973950] Call Trace:
[ 11.973950] [<819bbaff>] dump_stack+0x48/0x60
[ 11.973950] [<819bbaff>] dump_stack+0x48/0x60
[ 11.973950] [<81078dcf>] __lock_acquire.isra.22+0x1bf/0xc10
[ 11.973950] [<81078dcf>] __lock_acquire.isra.22+0x1bf/0xc10
[ 11.973950] [<81079fa7>] lock_acquire+0x77/0xa0
[ 11.973950] [<81079fa7>] lock_acquire+0x77/0xa0
[ 11.973950] [<817ca7ab>] ? dev_get_stats+0xcb/0x130
[ 11.973950] [<817ca7ab>] ? dev_get_stats+0xcb/0x130
[ 11.973950] [<8183862d>] ip_tunnel_get_stats64+0x6d/0x230
[ 11.973950] [<8183862d>] ip_tunnel_get_stats64+0x6d/0x230
[ 11.973950] [<817ca7ab>] ? dev_get_stats+0xcb/0x130
[ 11.973950] [<817ca7ab>] ? dev_get_stats+0xcb/0x130
[ 11.973950] [<811cf8c1>] ? __nla_reserve+0x21/0xd0
[ 11.973950] [<811cf8c1>] ? __nla_reserve+0x21/0xd0
[ 11.973950] [<817ca7ab>] dev_get_stats+0xcb/0x130
[ 11.973950] [<817ca7ab>] dev_get_stats+0xcb/0x130
[ 11.973950] [<817d5409>] rtnl_fill_ifinfo+0x569/0xe20
[ 11.973950] [<817d5409>] rtnl_fill_ifinfo+0x569/0xe20
[ 11.973950] [<810352e0>] ? kvm_clock_read+0x20/0x30
[ 11.973950] [<810352e0>] ? kvm_clock_read+0x20/0x30
[ 11.973950] [<81008e38>] ? sched_clock+0x8/0x10
[ 11.973950] [<81008e38>] ? sched_clock+0x8/0x10
[ 11.973950] [<8106ba45>] ? sched_clock_local+0x25/0x170
[ 11.973950] [<8106ba45>] ? sched_clock_local+0x25/0x170
[ 11.973950] [<810da6bd>] ? __kmalloc+0x3d/0x90
[ 11.973950] [<810da6bd>] ? __kmalloc+0x3d/0x90
[ 11.973950] [<817b8c10>] ? __kmalloc_reserve.isra.41+0x20/0x70
[ 11.973950] [<817b8c10>] ? __kmalloc_reserve.isra.41+0x20/0x70
[ 11.973950] [<810da81a>] ? slob_alloc_node+0x2a/0x60
[ 11.973950] [<810da81a>] ? slob_alloc_node+0x2a/0x60
[ 11.973950] [<817b919a>] ? __alloc_skb+0x6a/0x2b0
[ 11.973950] [<817b919a>] ? __alloc_skb+0x6a/0x2b0
[ 11.973950] [<817d8795>] rtmsg_ifinfo+0x65/0xe0
[ 11.973950] [<817d8795>] rtmsg_ifinfo+0x65/0xe0
[ 11.973950] [<817cbd31>] register_netdevice+0x531/0x5a0
[ 11.973950] [<817cbd31>] register_netdevice+0x531/0x5a0
[ 11.973950] [<81892b87>] ? ip6_tnl_get_cap+0x27/0x90
[ 11.973950] [<81892b87>] ? ip6_tnl_get_cap+0x27/0x90
[ 11.973950] [<817cbdb6>] register_netdev+0x16/0x30
[ 11.973950] [<817cbdb6>] register_netdev+0x16/0x30
[ 11.973950] [<81f574a6>] vti6_init_net+0x1c4/0x1d4
[ 11.973950] [<81f574a6>] vti6_init_net+0x1c4/0x1d4
[ 11.973950] [<81f573af>] ? vti6_init_net+0xcd/0x1d4
[ 11.973950] [<81f573af>] ? vti6_init_net+0xcd/0x1d4
[ 11.973950] [<817c16df>] ops_init.constprop.11+0x17f/0x1c0
[ 11.973950] [<817c16df>] ops_init.constprop.11+0x17f/0x1c0
[ 11.973950] [<817c1779>] register_pernet_operations.isra.9+0x59/0x90
[ 11.973950] [<817c1779>] register_pernet_operations.isra.9+0x59/0x90
[ 11.973950] [<817c18d1>] register_pernet_device+0x21/0x60
[ 11.973950] [<817c18d1>] register_pernet_device+0x21/0x60
[ 11.973950] [<81f574b6>] ? vti6_init_net+0x1d4/0x1d4
[ 11.973950] [<81f574b6>] ? vti6_init_net+0x1d4/0x1d4
[ 11.973950] [<81f574c7>] vti6_tunnel_init+0x11/0x68
[ 11.973950] [<81f574c7>] vti6_tunnel_init+0x11/0x68
[ 11.973950] [<81f572a1>] ? mip6_init+0x73/0xb4
[ 11.973950] [<81f572a1>] ? mip6_init+0x73/0xb4
[ 11.973950] [<81f0cba4>] do_one_initcall+0xbb/0x15b
[ 11.973950] [<81f0cba4>] do_one_initcall+0xbb/0x15b
[ 11.973950] [<811a00d8>] ? sha_transform+0x528/0x1150
[ 11.973950] [<811a00d8>] ? sha_transform+0x528/0x1150
[ 11.973950] [<81f0c544>] ? repair_env_string+0x12/0x51
[ 11.973950] [<81f0c544>] ? repair_env_string+0x12/0x51
[ 11.973950] [<8105c30d>] ? parse_args+0x2ad/0x440
[ 11.973950] [<8105c30d>] ? parse_args+0x2ad/0x440
[ 11.973950] [<810546be>] ? __usermodehelper_set_disable_depth+0x3e/0x50
[ 11.973950] [<810546be>] ? __usermodehelper_set_disable_depth+0x3e/0x50
[ 11.973950] [<81f0cd27>] kernel_init_freeable+0xe3/0x182
[ 11.973950] [<81f0cd27>] kernel_init_freeable+0xe3/0x182
[ 11.973950] [<81f0c532>] ? do_early_param+0x7a/0x7a
[ 11.973950] [<81f0c532>] ? do_early_param+0x7a/0x7a
[ 11.973950] [<819b5b1b>] kernel_init+0xb/0x100
[ 11.973950] [<819b5b1b>] kernel_init+0xb/0x100
[ 11.973950] [<819cebf7>] ret_from_kernel_thread+0x1b/0x28
[ 11.973950] [<819cebf7>] ret_from_kernel_thread+0x1b/0x28
[ 11.973950] [<819b5b10>] ? rest_init+0xc0/0xc0
[ 11.973950] [<819b5b10>] ? rest_init+0xc0/0xc0
Before 469bdcefdc ("ipv6: fix the use of pcpu_tstats in ip6_vti.c"),
the pcpu_tstats.syncp is not used to pretect the 64bit elements of
pcpu_tstats, so not appear this calltrace.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
---
net/ipv6/ip6_vti.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/ipv6/ip6_vti.c b/net/ipv6/ip6_vti.c
index a4564b0..7b42d5e 100644
--- a/net/ipv6/ip6_vti.c
+++ b/net/ipv6/ip6_vti.c
@@ -732,12 +732,18 @@ static void vti6_dev_setup(struct net_device *dev)
static inline int vti6_dev_init_gen(struct net_device *dev)
{
struct ip6_tnl *t = netdev_priv(dev);
+ int i;
t->dev = dev;
t->net = dev_net(dev);
dev->tstats = alloc_percpu(struct pcpu_tstats);
if (!dev->tstats)
return -ENOMEM;
+ for_each_possible_cpu(i) {
+ struct pcpu_tstats *stats;
+ stats = per_cpu_ptr(dev->tstats, i);
+ u64_stats_init(&stats->syncp);
+ }
return 0;
}
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH net-next 0/2] Pack struct xfrm_usersa_info and struct xfrm_userpolicy_info
From: Steffen Klassert @ 2014-01-07 7:47 UTC (permalink / raw)
To: Fan Du; +Cc: davem, stephen, dev, netdev
In-Reply-To: <1389077339-12814-1-git-send-email-fan.du@windriver.com>
On Tue, Jan 07, 2014 at 02:48:57PM +0800, Fan Du wrote:
> When trying to setup IPsec configuration on a 64bits host with
> iproute2(32bits compiled), the intened xfrm policy and sa is
> either deficit or wrong when kernel trying to parse user land
> information.
>
> Further investigatino shows that:
> L: kernel
> R: iproute2
>
> sizeof userpolicy usersa
> 64bits(unpacked) 168/168 224/224
> 32bits(unpacked) 164/164 220/220
> ^ ^
> L R
>
> To keep kernel and user land see a consistent structure, after
> add packing attribute, now it looks like this:
>
> 64bits( packed) 164/164 217/217
> 32bits( packed) 164/164 217/217
> ^ ^
> L R
>
We don't change userspace exported structures. This breaks
existing userspace tools.
^ permalink raw reply
* Re: [PATCH net-next 0/2] Pack struct xfrm_usersa_info and struct xfrm_userpolicy_info
From: Fan Du @ 2014-01-07 7:59 UTC (permalink / raw)
To: Steffen Klassert; +Cc: stephen, netdev, davem, dev
In-Reply-To: <20140107074724.GV31491@secunet.com>
On 2014年01月07日 15:47, Steffen Klassert wrote:
> On Tue, Jan 07, 2014 at 02:48:57PM +0800, Fan Du wrote:
>> When trying to setup IPsec configuration on a 64bits host with
>> iproute2(32bits compiled), the intened xfrm policy and sa is
>> either deficit or wrong when kernel trying to parse user land
>> information.
>>
>> Further investigatino shows that:
>> L: kernel
>> R: iproute2
>>
>> sizeof userpolicy usersa
>> 64bits(unpacked) 168/168 224/224
>> 32bits(unpacked) 164/164 220/220
>> ^ ^
>> L R
>>
>> To keep kernel and user land see a consistent structure, after
>> add packing attribute, now it looks like this:
>>
>> 64bits( packed) 164/164 217/217
>> 32bits( packed) 164/164 217/217
>> ^ ^
>> L R
>>
>
> We don't change userspace exported structures. This breaks
> existing userspace tools.
>
Then user with 32bits iproute2 or StrongSwan has to rebuild as 64bits?
--
浮沉随浪只记今朝笑
--fan
_______________________________________________
Dev mailing list
Dev@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/dev
^ permalink raw reply
* Re: [PATCH v4 1/2] netfilter_queue: enable UID/GID socket info retrieval
From: Valentina Giusti @ 2014-01-07 8:11 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: netfilter-devel, netdev, jpa, fw, daniel.wagner
In-Reply-To: <20131223142118.GA4803@localhost>
On 12/23/2013 03:21 PM, Pablo Neira Ayuso wrote:
> On Fri, Dec 20, 2013 at 05:28:53PM +0100, valentina.giusti@bmw-carit.de wrote:
>> From: Valentina Giusti <valentina.giusti@bmw-carit.de>
>>
>> Thanks to commits 41063e9 (ipv4: Early TCP socket demux) and 421b388 (udp: ipv4:
>> Add udp early demux) it is now possible to parse UID and GID socket info
>> also for incoming TCP and UDP connections. Having this info available, it
>> is convenient to let NFQUEUE parse it in order to improve and refine the
>> traffic analysis in userspace.
>
> Applied the kernel patch, wait for a new patch for libnetfilter_queue. Thanks.
>
Hi Pablo,
thanks for applying the kernel patch and also for the comments on the
userspace patch, I'll send a new patch that addresses them ASAP.
Sorry for the delay, I was away during the past 2 weeks.
BR,
- Val
^ permalink raw reply
* Re: [PATCH net 2/2] net: core: explicitly select a txq before doing l2 forwarding
From: John Fastabend @ 2014-01-07 8:22 UTC (permalink / raw)
To: Jason Wang; +Cc: davem, netdev, linux-kernel, mst, Neil Horman, e1000-devel
In-Reply-To: <1388978467-2075-2-git-send-email-jasowang@redhat.com>
On 1/5/2014 7:21 PM, Jason Wang wrote:
> Currently, the tx queue were selected implicitly in ndo_dfwd_start_xmit(). The
> will cause several issues:
>
> - NETIF_F_LLTX was forced for macvlan device in this case which lead extra lock
> contention.
> - dev_hard_start_xmit() was called with NULL txq which bypasses the net device
> watchdog
> - dev_hard_start_xmit() does not check txq everywhere which will lead a crash
> when tso is disabled for lower device.
>
> Fix this by explicitly introducing a select queue method just for l2 forwarding
> offload (ndo_dfwd_select_queue), and introducing dfwd_direct_xmit() to do the
> queue selecting and transmitting for l2 forwarding.
>
> With this fixes, NETIF_F_LLTX could be preserved for macvlan and there's no need
> to check txq against NULL in dev_hard_start_xmit().
>
> In the future, it was also required for macvtap l2 forwarding support since it
> provides a necessary synchronization method.
>
> Cc: John Fastabend <john.r.fastabend@intel.com>
> Cc: Neil Horman <nhorman@tuxdriver.com>
> Cc: e1000-devel@lists.sourceforge.net
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
[...]
> index 4fc1722..bc2b03f 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -2538,6 +2538,32 @@ static inline int skb_needs_linearize(struct sk_buff *skb,
> !(features & NETIF_F_SG)));
> }
>
> +int dfwd_direct_xmit(struct sk_buff *skb, struct net_device *dev,
> + void *accel_priv)
> +{
> + struct netdev_queue *txq;
> + int ret = NETDEV_TX_BUSY;
> + int index;
> +
> + BUG_ON(!dev->netdev_ops->ndo_dfwd_select_queue);
> + index = dev->netdev_ops->ndo_dfwd_select_queue(dev, skb,
> + accel_priv);
> +
> + local_bh_disable();
> +
> + skb_set_queue_mapping(skb, index);
How about replacing the index calculation and skb_set_queue_mapping with
netdev_pick_tx(). Then we don't need to add a new op and the existing
XPS, tx hash and select_queue() op works.
> + txq = netdev_get_tx_queue(dev, index);
> +
> + HARD_TX_LOCK(dev, txq, smp_processor_id());
> + if (!netif_xmit_frozen_or_stopped(txq))
> + ret = dev_hard_start_xmit(skb, dev, txq, accel_priv);
> + HARD_TX_UNLOCK(dev, txq);
> +
> + local_bh_enable();
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(dfwd_direct_xmit);
> +
> int dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev,
> struct netdev_queue *txq, void *accel_priv)
> {
> @@ -2611,7 +2637,7 @@ int dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev,
> rc = ops->ndo_start_xmit(skb, dev);
>
> trace_net_dev_xmit(skb, rc, dev, skb_len);
> - if (rc == NETDEV_TX_OK && txq)
> + if (rc == NETDEV_TX_OK)
> txq_trans_update(txq);
Removing the check here rather than adding more checks in the gso case
as I suggested in the other thread seems cleaner.
Thanks!
John
> return rc;
> }
>
^ permalink raw reply
* Re: [PATCH net 2/2] net: core: explicitly select a txq before doing l2 forwarding
From: John Fastabend @ 2014-01-07 8:37 UTC (permalink / raw)
To: Jason Wang; +Cc: davem, netdev, linux-kernel, mst, Neil Horman, e1000-devel
In-Reply-To: <52CBB94D.6010405@intel.com>
[...]
>>
>> +int dfwd_direct_xmit(struct sk_buff *skb, struct net_device *dev,
>> + void *accel_priv)
>> +{
>> + struct netdev_queue *txq;
>> + int ret = NETDEV_TX_BUSY;
>> + int index;
>> +
>> + BUG_ON(!dev->netdev_ops->ndo_dfwd_select_queue);
>> + index = dev->netdev_ops->ndo_dfwd_select_queue(dev, skb,
>> + accel_priv);
>> +
>> + local_bh_disable();
>> +
>> + skb_set_queue_mapping(skb, index);
>
> How about replacing the index calculation and skb_set_queue_mapping with
> netdev_pick_tx(). Then we don't need to add a new op and the existing
> XPS, tx hash and select_queue() op works.
>
Sorry for the noise that was dumb it wouldn't work.
^ permalink raw reply
* [PATCH -next] i40evf: use pci drvdata correctly in i40evf_suspend()
From: Wei Yongjun @ 2014-01-07 8:53 UTC (permalink / raw)
To: jeffrey.t.kirsher, jesse.brandeburg, bruce.w.allan,
carolyn.wyborny, donald.c.skidmore, gregory.v.rose,
alexander.h.duyck, john.ronciak, mitch.a.williams
Cc: yongjun_wei, e1000-devel, netdev
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
We had set the pci driver-specific data in i40evf_probe() as
a type of struct net_device, so we should use it as netdev
in i40evf_resume().
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
drivers/net/ethernet/intel/i40evf/i40evf_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_main.c b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
index 06bf8253..a495ec4 100644
--- a/drivers/net/ethernet/intel/i40evf/i40evf_main.c
+++ b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
@@ -2216,8 +2216,8 @@ static int i40evf_suspend(struct pci_dev *pdev, pm_message_t state)
**/
static int i40evf_resume(struct pci_dev *pdev)
{
- struct i40evf_adapter *adapter = pci_get_drvdata(pdev);
- struct net_device *netdev = adapter->netdev;
+ struct net_device *netdev = pci_get_drvdata(pdev);
+ struct i40evf_adapter *adapter = netdev_priv(netdev);
u32 err;
pci_set_power_state(pdev, PCI_D0);
^ permalink raw reply related
* [PATCH -next] net/mlx4_en: fix error return code in mlx4_en_get_qp()
From: Wei Yongjun @ 2014-01-07 8:56 UTC (permalink / raw)
To: amirv, ogerlitz, davem; +Cc: yongjun_wei, netdev
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Fix to return a negative error code from the error handling
case instead of 0.
Fixes: 837052d0ccc5 ('net/mlx4_en: Add netdev support for TCP/IP offloads of vxlan tunneling')
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
index 60b927e..fad4531 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_netdev.c
@@ -632,8 +632,9 @@ static int mlx4_en_get_qp(struct mlx4_en_priv *priv)
if (err)
goto steer_err;
- if (mlx4_en_tunnel_steer_add(priv, priv->dev->dev_addr, *qpn,
- &priv->tunnel_reg_id))
+ err = mlx4_en_tunnel_steer_add(priv, priv->dev->dev_addr, *qpn,
+ &priv->tunnel_reg_id);
+ if (err)
goto tunnel_err;
entry = kmalloc(sizeof(*entry), GFP_KERNEL);
^ permalink raw reply related
* Re: [PATCH net 1/2] macvlan: forbid L2 fowarding offload for macvtap
From: Jason Wang @ 2014-01-07 9:00 UTC (permalink / raw)
To: John Fastabend
Cc: John Fastabend, Neil Horman, davem, netdev, linux-kernel, mst,
Vlad Yasevich
In-Reply-To: <52CBAC2A.90005@intel.com>
On 01/07/2014 03:26 PM, John Fastabend wrote:
> [...]
>
>>>> Unfortunately not. This commit has a side effect that it in fact
>>>> disables the multiqueue macvtap transmission. Since all macvtap queues
>>>> will contend on a single qdisc lock.
>>>>
>>>
>>> They will only contend on a single qdisc lock if the lower device has
>>> 1 queue.
>>
>> I think we are talking about 6acf54f1cf0a6747bac9fea26f34cfc5a9029523.
>
> Yes.
>
>>
>> The qdisc or txq lock were macvlan device itself since dev_queue_xmit()
>> was called for macvlan device itself. So even if lower device has
>> multiple txqs, if you just create a one queue macvlan device, you will
>> get lock contention on macvlan device. And even if you explicitly
>> specifying the txq numbers ( though I don't believe most management
>> software will do this) when creating the macvlan/macvtap device, you
>> must also configure the XPS for macvlan to make sure it has the
>> possibility of using multiple transmit queues.
>>
>
> OK I think I'm finally putting all the pieces together thanks.
>
> Do you know why macvtap is setting dev->tx_queue_len by default? If you
> zero this then the noqueue_qdisc is used and the q->enqueue check in
> dev_queue_xmit will fail.
It was introduced in commit 8a35747a5d13b99e076b0222729e0caa48cb69b6
("macvtap: Limit packet queue length") to limit the length of socket
receive queue of macvtap. But I'm not sure whether the qdisc is a
byproduct of this commit, maybe we can switch to use another name
instead of just reuse dev->tx_queue_length.
>
> Also if XPS is not configured then skb_tx_hash is used so multiple
> transmit queues will still be used.
>
True.
>>> Perhaps defaulting the L2 forwarding devices to 1queue was a
>>> mistake. But the same issue arises when running macvtap over a
>>> non-multiqueue nic. Or even if you have a multiqueue device and create
>>> many more macvtap queues than the lower device has queues.
>>>
>>> Shouldn't the macvtap configuration take into account the lowest level
>>> devices queues?
>>
>> See commit 8ffab51b3dfc54876f145f15b351c41f3f703195 ("macvlan: lockless
>> tx path"). It allows the management to create a device without worrying
>> the underlying device.
>
> OK.
>
>>> How does using the L2 forwarding device change the
>>> contention issues? Without the L2 forwarding LLTX is enabled but the
>>> qdisc lock, etc is still acquired on the device below the macvlan.
>>>
>>
>> That's the point. We need make sure the txq selection and qdisc lock
>> were done for the lower device not for the macvlan device itself. Then
>> macvlan can automatically benefit from the multi-queue capable lower
>> devices. But L2 forwarding needs to contend on the txq lock on macvlan
>> device itself, which is unnecessary and can complex the management.
>
> If I make the l2 forwarding defaults a bit better then using the L2
> forwarding case should not be any more complex. And because the queues
> are dedicated to the macvtap device any contention from qdisc lock, etc
> comes from the upper device only.
At very least the txq of lower device should be held in order to be
synchronized with management path. Consider txq lock were often held by
netif_tx_disable() before trying to down the card. Current cold does not
hold txq lock, so it loses the synchronization which may cause issues.
And the code also does not check whether the txq has been stopped before
trying to start the transmission.
> Also if I get the bandwidth controls
> in we can set the max/min bandwidth per macvtap device this way. That
> is future work though.
>
That will be a nice feature.
>>> The ixgbe driver as it is currently written can be configured for up to
>>> 4 queues by setting numtxqueues when the device is created. I assume
>>> when creating macvtap queues the user needs to account for the number
>>> of queues supported by the lower device.
>>>
>>
>> We'd better not complicate the task of management, lockless tx path work
>> very well so we can just keep it. Btw, there's no way for the user to
>> know the maximum number of queues that L2 forwarding supports.
>
> Good point I'll add an attribute to query it.
>
>>>> For L2 forwarding offload itself, more issues need to be addressed for
>>>> multiqueue macvtap:
>>>>
>>>> - ndo_dfwd_add_station() can only create queues per device at
>>>> ndo_open,
>>>> but multiqueue macvtap allows user to create and destroy queues at
>>>> their
>>>> will and at any time.
>>>
>>> same argument as above, isn't this the same when running macvtap
>>> without
>>> the l2 offloads over a real device? I expect you hit the same
>>> contention
>>> points when running over a real device.
>>
>> Not true and not only for contention.
>>
>> Macvtap allows user to create or destroy a queue by simply open or close
>> to character device /dev/tapX. But currently, we do nothing when a new
>> queue was created or destroyed for L2 forwarding offload.
>>
>> For contention, lockless tx path make the contention only happens for
>> the txq or qdisc for the lower device, but L2 forwarding offload make
>> contention also happen for the macvlan device itself.
>
> Right, but there will be less contention there because those queues
> are a dedicated resource for the upper device.
Yes and this is also true if we only do synchronization on the lower
device since only dedicated queues could be selected.
>
> At this point I think I need to put together a real testbed and
> benchmark some of this with netperf and perf running to get real
> numbers. When I originally did the l2 forwarding I did not do any
> testing with multiple macvtap queues and only very limited work with
> macvtap.
>
As I said above, holding the txq lock of lower device seems a must and
we should not get regression if NETIF_F_LLTX is kept. But I agree we
need some test.
>>
>>>
>>>
>>>> - it looks that ixgbe has a upper limit of 4 queues per station, but
>>>> macvtap currently allows up to 16 queues per device.
>>>>
>>>
>>> The 4 limit was to simplify the code because the queue mapping in the
>>> driver gets complicated if it is greater than 4. We can probably
>>> increase this latter. But sorry reiterating how is this different than
>>> a macvtap on a real device that supports a max of 4 queues?
>>
>> Well, it maybe easy. I just point out possible issues we may meet
>> currently.
>
> Right.
>
>>>
>>>> So more works need to be done and unless those above 3 issues were
>>>> addressed, this patch is really needed to make sure macvtap works.
>>>>
>>>
>>> Agreed there is a lot more work here to improve things I'm just not
>>> sure we need to disable this now. Also note its the l2 forwarding
>>> should be disabled by default so a user would have to enable the
>>> feature flag.
>>
>> Even if it was disabled by default. We should not surprise the user who
>> want to enable it for macvtap.
>
> So the question is what to do in net while we improve net-next. Either
> we fix the crash from the null txq and note that with l2 forwarding
> some non default configuration is needed for optimal performance OR
> for now disable it as your patch does. I would prefer to fix the crash
> and note the configuration but I see your point about surprising users
> so could go either way.
>
It's much safer to disable l2 forwarding offload for macvtap temporarily
consider it has several issues.We can re-enable it when everything is
ready in net-next. We we really need to hold the txq lock of lower
device, only add more check of NULL pointer is not sufficient. So
explicitly select a txq is still needed. And I don't see any conflicts
between this and future enhancement.
Also I don't see any drawback of using NETIF_F_LLTX for l2 forwarding.
So we'd better keep it.
> Neil any thoughts?
>
> To fix the null txq in the gso case adding a check for a non-null
> txq before calling txq_trans_update() makes sense to me. We already
> have the check in the non-gso case so making it symmetric fixes it.
>
>>>
>>> Thanks,
>>> John
>>>
>>
>> Thanks
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [net-next 00/15][pull request] Intel Wired LAN Driver Updates
From: Jeff Kirsher @ 2014-01-07 9:32 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, gospo, sassmann
This series contains updates to i40e only.
Anjali adds more functionality to debugfs to assist development and
testing of admin queue commands.
Greg makes sure broadcast promiscuous is disabled by default, otherwise
VLAN tagged packets out of the assigned VLAN domain are received. Also
provides a fix when the 8021q driver is loaded, so that VLAN 0 tagged
packets are accepted so that upper layers can interpret the priority
bits. Then provides a fix to let the VF to request the PF to set its
already assigned MAC address without generating an error. Greg also
adds helper functions to enable or disable internal switch loopback
when VFs are created or destroyed via the sysfs interface.
Shannon provides most of the changes, where he adds code to ensure
that the hardware waits to make sure that the firmware is ready as well
after reset. Also updates the code to use the new features in the
firmware. Provides a fix while in MFP mode where resources are
reduced, so use a smaller range of test registers than when in SFP mode.
Moves the PF ID initialization code to earlier in the driver
initialization function since a few operations need the information
before the first PF reset is called. Shannon adds a check for MAC
type before reading anything from the registers to ensure we dealing
with the correct MAC type. Then reworks Shadow RAM read word/buffer
functions as to not block whole NVM resources for SR read operations.
Mitch lastly provides a fix to correctly setup ARQ descriptors in
the cleanup code.
Catherine bumps the driver version due to all the recent changes.
The following are changes since commit 83111e7fe85f2dc8b61e463c71b971f4998d8e53:
netfilter: Fix build failure in nfnetlink_queue_core.c.
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next master
Anjali Singhai Jain (1):
i40e: Expose AQ debugfs hooks
Catherine Sullivan (1):
i40e: Bump version
Greg Rose (4):
i40e: Do not enable broadcast promiscuous by default
i40e: Stop accepting any VLAN tag on VLAN 0 filter set
i40e: Allow VF to set already assigned MAC address
i40e: Enable/Disable PF switch LB on SR-IOV configure changes
Kamil Krawczyk (1):
i40e: remove redundant AQ enable
Mitch Williams (1):
i40e: correctly setup ARQ descriptors
Shannon Nelson (7):
i40e: Add code to wait for FW to complete in reset path
i40e: update firmware api to 1.1
i40e: Reduce range of interrupt reg in reg test
i40e: move PF ID init from PF reset to SC init
i40e: check MAC type before any REG access
i40e: rework shadow ram read functions
i40e: whitespace paren and comment tweaks
drivers/net/ethernet/intel/i40e/i40e_adminq.c | 27 ++---
drivers/net/ethernet/intel/i40e/i40e_adminq_cmd.h | 126 +++++++++++++++------
drivers/net/ethernet/intel/i40e/i40e_common.c | 51 ++++++---
drivers/net/ethernet/intel/i40e/i40e_debugfs.c | 112 ++++++++++++++++++
drivers/net/ethernet/intel/i40e/i40e_diag.c | 6 +-
drivers/net/ethernet/intel/i40e/i40e_main.c | 29 ++---
drivers/net/ethernet/intel/i40e/i40e_nvm.c | 67 +++--------
drivers/net/ethernet/intel/i40e/i40e_register.h | 22 ++++
drivers/net/ethernet/intel/i40e/i40e_type.h | 11 +-
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 100 +++++++++++++---
10 files changed, 395 insertions(+), 156 deletions(-)
--
1.8.3.1
^ permalink raw reply
* [net-next 01/15] i40e: Expose AQ debugfs hooks
From: Jeff Kirsher @ 2014-01-07 9:32 UTC (permalink / raw)
To: davem
Cc: Anjali Singhai Jain, netdev, gospo, sassmann, Jesse Brandeburg,
Jeff Kirsher
In-Reply-To: <1389087149-27962-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Anjali Singhai Jain <anjali.singhai@intel.com>
Add more functionality to debugfs to assist development
and testing of AQ commands.
adds:
send aq_cmd
send indirect aq_cmd
Change-Id: I01710cddd33110a6c1e1aabf84cb6e93cda4c42a
Signed-off-by: Anjali Singhai Jain <anjali.singhai@intel.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Kavindya Deegala <kavindya.s.deegala@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_debugfs.c | 112 +++++++++++++++++++++++++
1 file changed, 112 insertions(+)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_debugfs.c b/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
index 45bdcca..a236f59 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_debugfs.c
@@ -1523,6 +1523,116 @@ static ssize_t i40e_dbg_command_write(struct file *filp,
} else {
dev_info(&pf->pdev->dev, "clear_stats vsi [seid] or clear_stats pf\n");
}
+ } else if (strncmp(cmd_buf, "send aq_cmd", 11) == 0) {
+ struct i40e_aq_desc *desc;
+ i40e_status ret;
+ desc = kzalloc(sizeof(struct i40e_aq_desc), GFP_KERNEL);
+ if (!desc)
+ goto command_write_done;
+ cnt = sscanf(&cmd_buf[11],
+ "%hx %hx %hx %hx %x %x %x %x %x %x",
+ &desc->flags,
+ &desc->opcode, &desc->datalen, &desc->retval,
+ &desc->cookie_high, &desc->cookie_low,
+ &desc->params.internal.param0,
+ &desc->params.internal.param1,
+ &desc->params.internal.param2,
+ &desc->params.internal.param3);
+ if (cnt != 10) {
+ dev_info(&pf->pdev->dev,
+ "send aq_cmd: bad command string, cnt=%d\n",
+ cnt);
+ kfree(desc);
+ desc = NULL;
+ goto command_write_done;
+ }
+ ret = i40e_asq_send_command(&pf->hw, desc, NULL, 0, NULL);
+ if (!ret) {
+ dev_info(&pf->pdev->dev, "AQ command sent Status : Success\n");
+ } else if (ret == I40E_ERR_ADMIN_QUEUE_ERROR) {
+ dev_info(&pf->pdev->dev,
+ "AQ command send failed Opcode %x AQ Error: %d\n",
+ desc->opcode, pf->hw.aq.asq_last_status);
+ } else {
+ dev_info(&pf->pdev->dev,
+ "AQ command send failed Opcode %x Status: %d\n",
+ desc->opcode, ret);
+ }
+ dev_info(&pf->pdev->dev,
+ "AQ desc WB 0x%04x 0x%04x 0x%04x 0x%04x 0x%08x 0x%08x 0x%08x 0x%08x 0x%08x 0x%08x\n",
+ desc->flags, desc->opcode, desc->datalen, desc->retval,
+ desc->cookie_high, desc->cookie_low,
+ desc->params.internal.param0,
+ desc->params.internal.param1,
+ desc->params.internal.param2,
+ desc->params.internal.param3);
+ kfree(desc);
+ desc = NULL;
+ } else if (strncmp(cmd_buf, "send indirect aq_cmd", 20) == 0) {
+ struct i40e_aq_desc *desc;
+ i40e_status ret;
+ u16 buffer_len;
+ u8 *buff;
+ desc = kzalloc(sizeof(struct i40e_aq_desc), GFP_KERNEL);
+ if (!desc)
+ goto command_write_done;
+ cnt = sscanf(&cmd_buf[20],
+ "%hx %hx %hx %hx %x %x %x %x %x %x %hd",
+ &desc->flags,
+ &desc->opcode, &desc->datalen, &desc->retval,
+ &desc->cookie_high, &desc->cookie_low,
+ &desc->params.internal.param0,
+ &desc->params.internal.param1,
+ &desc->params.internal.param2,
+ &desc->params.internal.param3,
+ &buffer_len);
+ if (cnt != 11) {
+ dev_info(&pf->pdev->dev,
+ "send indirect aq_cmd: bad command string, cnt=%d\n",
+ cnt);
+ kfree(desc);
+ desc = NULL;
+ goto command_write_done;
+ }
+ /* Just stub a buffer big enough in case user messed up */
+ if (buffer_len == 0)
+ buffer_len = 1280;
+
+ buff = kzalloc(buffer_len, GFP_KERNEL);
+ if (!buff) {
+ kfree(desc);
+ desc = NULL;
+ goto command_write_done;
+ }
+ desc->flags |= cpu_to_le16((u16)I40E_AQ_FLAG_BUF);
+ ret = i40e_asq_send_command(&pf->hw, desc, buff,
+ buffer_len, NULL);
+ if (!ret) {
+ dev_info(&pf->pdev->dev, "AQ command sent Status : Success\n");
+ } else if (ret == I40E_ERR_ADMIN_QUEUE_ERROR) {
+ dev_info(&pf->pdev->dev,
+ "AQ command send failed Opcode %x AQ Error: %d\n",
+ desc->opcode, pf->hw.aq.asq_last_status);
+ } else {
+ dev_info(&pf->pdev->dev,
+ "AQ command send failed Opcode %x Status: %d\n",
+ desc->opcode, ret);
+ }
+ dev_info(&pf->pdev->dev,
+ "AQ desc WB 0x%04x 0x%04x 0x%04x 0x%04x 0x%08x 0x%08x 0x%08x 0x%08x 0x%08x 0x%08x\n",
+ desc->flags, desc->opcode, desc->datalen, desc->retval,
+ desc->cookie_high, desc->cookie_low,
+ desc->params.internal.param0,
+ desc->params.internal.param1,
+ desc->params.internal.param2,
+ desc->params.internal.param3);
+ print_hex_dump(KERN_INFO, "AQ buffer WB: ",
+ DUMP_PREFIX_OFFSET, 16, 1,
+ buff, buffer_len, true);
+ kfree(buff);
+ buff = NULL;
+ kfree(desc);
+ desc = NULL;
} else if ((strncmp(cmd_buf, "add fd_filter", 13) == 0) ||
(strncmp(cmd_buf, "rem fd_filter", 13) == 0)) {
struct i40e_fdir_data fd_data;
@@ -1774,6 +1884,8 @@ static ssize_t i40e_dbg_command_write(struct file *filp,
dev_info(&pf->pdev->dev, " pfr\n");
dev_info(&pf->pdev->dev, " corer\n");
dev_info(&pf->pdev->dev, " globr\n");
+ dev_info(&pf->pdev->dev, " send aq_cmd <flags> <opcode> <datalen> <retval> <cookie_h> <cookie_l> <param0> <param1> <param2> <param3>\n");
+ dev_info(&pf->pdev->dev, " send indirect aq_cmd <flags> <opcode> <datalen> <retval> <cookie_h> <cookie_l> <param0> <param1> <param2> <param3> <buffer_len>\n");
dev_info(&pf->pdev->dev, " add fd_filter <dest q_index> <flex_off> <pctype> <dest_vsi> <dest_ctl> <fd_status> <cnt_index> <fd_id> <packet_len> <packet>\n");
dev_info(&pf->pdev->dev, " rem fd_filter <dest q_index> <flex_off> <pctype> <dest_vsi> <dest_ctl> <fd_status> <cnt_index> <fd_id> <packet_len> <packet>\n");
dev_info(&pf->pdev->dev, " lldp start\n");
--
1.8.3.1
^ permalink raw reply related
* [net-next 02/15] i40e: Do not enable broadcast promiscuous by default
From: Jeff Kirsher @ 2014-01-07 9:32 UTC (permalink / raw)
To: davem; +Cc: Greg Rose, netdev, gospo, sassmann, Jesse Brandeburg,
Jeff Kirsher
In-Reply-To: <1389087149-27962-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Greg Rose <gregory.v.rose@intel.com>
Broadcast promiscuous should only be turned on when general
promiscuous mode is turned on, otherwise VLAN tagged packets out of
the assigned VLAN domain are received.
Add a broadcast MAC filter in order to continue to receive
broadcast traffic on VLANs, MAIN or VMDQ VSI.
Change-Id: I99d8e382a082ee51201228f1226af3b46452ac55
Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Sibai Li <sibai.li@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 16 +++++++++-------
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 19 +++++++++----------
2 files changed, 18 insertions(+), 17 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 483126c..5ddbd54 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -1650,6 +1650,13 @@ int i40e_sync_vsi_filters(struct i40e_vsi *vsi)
dev_info(&pf->pdev->dev,
"set uni promisc failed, err %d, aq_err %d\n",
aq_ret, pf->hw.aq.asq_last_status);
+ aq_ret = i40e_aq_set_vsi_broadcast(&vsi->back->hw,
+ vsi->seid,
+ cur_promisc, NULL);
+ if (aq_ret)
+ dev_info(&pf->pdev->dev,
+ "set brdcast promisc failed, err %d, aq_err %d\n",
+ aq_ret, pf->hw.aq.asq_last_status);
}
clear_bit(__I40E_CONFIG_BUSY, &vsi->state);
@@ -3987,13 +3994,6 @@ static int i40e_open(struct net_device *netdev)
if (err)
goto err_up_complete;
- if ((vsi->type == I40E_VSI_MAIN) || (vsi->type == I40E_VSI_VMDQ2)) {
- err = i40e_aq_set_vsi_broadcast(&pf->hw, vsi->seid, true, NULL);
- if (err)
- netdev_info(netdev,
- "couldn't set broadcast err %d aq_err %d\n",
- err, pf->hw.aq.asq_last_status);
- }
#ifdef CONFIG_I40E_VXLAN
vxlan_get_rx_port(netdev);
#endif
@@ -6067,6 +6067,7 @@ static const struct net_device_ops i40e_netdev_ops = {
**/
static int i40e_config_netdev(struct i40e_vsi *vsi)
{
+ u8 brdcast[ETH_ALEN] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
struct i40e_pf *pf = vsi->back;
struct i40e_hw *hw = &pf->hw;
struct i40e_netdev_priv *np;
@@ -6116,6 +6117,7 @@ static int i40e_config_netdev(struct i40e_vsi *vsi)
random_ether_addr(mac_addr);
i40e_add_filter(vsi, mac_addr, I40E_VLAN_ANY, false, false);
}
+ i40e_add_filter(vsi, brdcast, I40E_VLAN_ANY, false, false);
memcpy(netdev->dev_addr, mac_addr, ETH_ALEN);
memcpy(netdev->perm_addr, mac_addr, ETH_ALEN);
diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
index 55ec2db..fee368a 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -369,7 +369,6 @@ static int i40e_alloc_vsi_res(struct i40e_vf *vf, enum i40e_vsi_type type)
{
struct i40e_mac_filter *f = NULL;
struct i40e_pf *pf = vf->pf;
- struct i40e_hw *hw = &pf->hw;
struct i40e_vsi *vsi;
int ret = 0;
@@ -383,6 +382,7 @@ static int i40e_alloc_vsi_res(struct i40e_vf *vf, enum i40e_vsi_type type)
goto error_alloc_vsi_res;
}
if (type == I40E_VSI_SRIOV) {
+ u8 brdcast[ETH_ALEN] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
vf->lan_vsi_index = vsi->idx;
vf->lan_vsi_id = vsi->id;
dev_info(&pf->pdev->dev,
@@ -398,6 +398,14 @@ static int i40e_alloc_vsi_res(struct i40e_vf *vf, enum i40e_vsi_type type)
i40e_vsi_add_pvid(vsi, vf->port_vlan_id);
f = i40e_add_filter(vsi, vf->default_lan_addr.addr,
vf->port_vlan_id, true, false);
+ if (!f)
+ dev_info(&pf->pdev->dev,
+ "Could not allocate VF MAC addr\n");
+ f = i40e_add_filter(vsi, brdcast, vf->port_vlan_id,
+ true, false);
+ if (!f)
+ dev_info(&pf->pdev->dev,
+ "Could not allocate VF broadcast filter\n");
}
if (!f) {
@@ -413,15 +421,6 @@ static int i40e_alloc_vsi_res(struct i40e_vf *vf, enum i40e_vsi_type type)
goto error_alloc_vsi_res;
}
- /* accept bcast pkts. by default */
- ret = i40e_aq_set_vsi_broadcast(hw, vsi->seid, true, NULL);
- if (ret) {
- dev_err(&pf->pdev->dev,
- "set vsi bcast failed for vf %d, vsi %d, aq_err %d\n",
- vf->vf_id, vsi->idx, pf->hw.aq.asq_last_status);
- ret = -EINVAL;
- }
-
error_alloc_vsi_res:
return ret;
}
--
1.8.3.1
^ permalink raw reply related
* [net-next 03/15] i40e: Stop accepting any VLAN tag on VLAN 0 filter set
From: Jeff Kirsher @ 2014-01-07 9:32 UTC (permalink / raw)
To: davem; +Cc: Greg Rose, netdev, gospo, sassmann, Jesse Brandeburg,
Jeff Kirsher
In-Reply-To: <1389087149-27962-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Greg Rose <gregory.v.rose@intel.com>
When the 8021q driver is loaded it sets VLAN 0 filters on all devices.
This does not mean that any VLAN tagged packet should be accepted.
Instead accept only VLAN 0 tagged packets so that upper layers can
interpret the priority bits.
Change-Id: I17274a540b613749612ffe23a3aef2b8ee6ff6a4
Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Sibai Li <sibai.li@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 11 -----------
1 file changed, 11 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 5ddbd54..2a42470 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -1509,11 +1509,6 @@ int i40e_sync_vsi_filters(struct i40e_vsi *vsi)
cpu_to_le16((u16)(f->vlan ==
I40E_VLAN_ANY ? 0 : f->vlan));
- /* vlan0 as wild card to allow packets from all vlans */
- if (f->vlan == I40E_VLAN_ANY ||
- (vsi->netdev && !(vsi->netdev->features &
- NETIF_F_HW_VLAN_CTAG_FILTER)))
- cmd_flags |= I40E_AQC_MACVLAN_DEL_IGNORE_VLAN;
cmd_flags |= I40E_AQC_MACVLAN_DEL_PERFECT_MATCH;
del_list[num_del].flags = cmd_flags;
num_del++;
@@ -1579,12 +1574,6 @@ int i40e_sync_vsi_filters(struct i40e_vsi *vsi)
add_list[num_add].queue_number = 0;
cmd_flags |= I40E_AQC_MACVLAN_ADD_PERFECT_MATCH;
-
- /* vlan0 as wild card to allow packets from all vlans */
- if (f->vlan == I40E_VLAN_ANY || (vsi->netdev &&
- !(vsi->netdev->features &
- NETIF_F_HW_VLAN_CTAG_FILTER)))
- cmd_flags |= I40E_AQC_MACVLAN_ADD_IGNORE_VLAN;
add_list[num_add].flags = cpu_to_le16(cmd_flags);
num_add++;
--
1.8.3.1
^ permalink raw reply related
* [net-next 04/15] i40e: Allow VF to set already assigned MAC address
From: Jeff Kirsher @ 2014-01-07 9:32 UTC (permalink / raw)
To: davem; +Cc: Greg Rose, netdev, gospo, sassmann, Jesse Brandeburg,
Jeff Kirsher
In-Reply-To: <1389087149-27962-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Greg Rose <gregory.v.rose@intel.com>
The VF is allowed to request the PF to set its already assigned
MAC address without generating an error.
Change-Id: I8dfdf353396995dbbb26cafab4e42b451911da3d
Signed-off-by: Greg Rose <gregory.v.rose@intel.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Acked-by: Shannon Nelson <shannon.nelson@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
index fee368a..5c99164 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -1348,10 +1348,13 @@ static inline int i40e_check_vf_permission(struct i40e_vf *vf, u8 *macaddr)
is_zero_ether_addr(macaddr)) {
dev_err(&pf->pdev->dev, "invalid VF MAC addr %pM\n", macaddr);
ret = I40E_ERR_INVALID_MAC_ADDR;
- } else if (vf->pf_set_mac && !is_multicast_ether_addr(macaddr)) {
+ } else if (vf->pf_set_mac && !is_multicast_ether_addr(macaddr) &&
+ !ether_addr_equal(macaddr, vf->default_lan_addr.addr)) {
/* If the host VMM administrator has set the VF MAC address
* administratively via the ndo_set_vf_mac command then deny
* permission to the VF to add or delete unicast MAC addresses.
+ * The VF may request to set the MAC address filter already
+ * assigned to it so do not return an error in that case.
*/
dev_err(&pf->pdev->dev,
"VF attempting to override administratively set MAC address\nPlease reload the VF driver to resume normal operation\n");
--
1.8.3.1
^ permalink raw reply related
* [net-next 06/15] i40e: Add code to wait for FW to complete in reset path
From: Jeff Kirsher @ 2014-01-07 9:32 UTC (permalink / raw)
To: davem
Cc: Shannon Nelson, netdev, gospo, sassmann, Anjali Singhai Jain,
Jeff Kirsher
In-Reply-To: <1389087149-27962-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Shannon Nelson <shannon.nelson@intel.com>
The RSTAT comes back with DEVICE READY to indicate that the HW is ready,
but we still have to wait for the FW to indicate that the Core and Global
modules are back up again. This needs a read of the NVM_ULD register.
Change-Id: I88276165f9cd446d2f166fb4b8cff00521af4bec
Signed-off-by: Anjali Singhai Jain <anjali.singhai@intel.com>
Signed-off-by: Shannon Nelson <shannon.nelson@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_common.c | 20 ++++++++++++++++++++
drivers/net/ethernet/intel/i40e/i40e_register.h | 22 ++++++++++++++++++++++
2 files changed, 42 insertions(+)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_common.c b/drivers/net/ethernet/intel/i40e/i40e_common.c
index 7cd59ce..337e913 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_common.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_common.c
@@ -335,6 +335,7 @@ static enum i40e_media_type i40e_get_media_type(struct i40e_hw *hw)
i40e_status i40e_pf_reset(struct i40e_hw *hw)
{
u32 cnt = 0;
+ u32 cnt1 = 0;
u32 reg = 0;
u32 grst_del;
@@ -355,6 +356,25 @@ i40e_status i40e_pf_reset(struct i40e_hw *hw)
return I40E_ERR_RESET_FAILED;
}
+ /* Now Wait for the FW to be ready */
+ for (cnt1 = 0; cnt1 < I40E_PF_RESET_WAIT_COUNT; cnt1++) {
+ reg = rd32(hw, I40E_GLNVM_ULD);
+ reg &= (I40E_GLNVM_ULD_CONF_CORE_DONE_MASK |
+ I40E_GLNVM_ULD_CONF_GLOBAL_DONE_MASK);
+ if (reg == (I40E_GLNVM_ULD_CONF_CORE_DONE_MASK |
+ I40E_GLNVM_ULD_CONF_GLOBAL_DONE_MASK)) {
+ hw_dbg(hw, "Core and Global modules ready %d\n", cnt1);
+ break;
+ }
+ usleep_range(10000, 20000);
+ }
+ if (!(reg & (I40E_GLNVM_ULD_CONF_CORE_DONE_MASK |
+ I40E_GLNVM_ULD_CONF_GLOBAL_DONE_MASK))) {
+ hw_dbg(hw, "wait for FW Reset complete timedout\n");
+ hw_dbg(hw, "I40E_GLNVM_ULD = 0x%x\n", reg);
+ return I40E_ERR_RESET_FAILED;
+ }
+
/* Determine the PF number based on the PCI fn */
reg = rd32(hw, I40E_GLPCI_CAPSUP);
if (reg & I40E_GLPCI_CAPSUP_ARI_EN_MASK)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_register.h b/drivers/net/ethernet/intel/i40e/i40e_register.h
index 2394c66..d188ec0 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_register.h
+++ b/drivers/net/ethernet/intel/i40e/i40e_register.h
@@ -2053,6 +2053,28 @@
#define I40E_GLNVM_SRDATA_WRDATA_MASK (0xFFFF << I40E_GLNVM_SRDATA_WRDATA_SHIFT)
#define I40E_GLNVM_SRDATA_RDDATA_SHIFT 16
#define I40E_GLNVM_SRDATA_RDDATA_MASK (0xFFFF << I40E_GLNVM_SRDATA_RDDATA_SHIFT)
+#define I40E_GLNVM_ULD 0x000B6008
+#define I40E_GLNVM_ULD_CONF_PCIR_DONE_SHIFT 0
+#define I40E_GLNVM_ULD_CONF_PCIR_DONE_MASK (0x1 << I40E_GLNVM_ULD_CONF_PCIR_DONE_SHIFT)
+#define I40E_GLNVM_ULD_CONF_PCIRTL_DONE_SHIFT 1
+#define I40E_GLNVM_ULD_CONF_PCIRTL_DONE_MASK (0x1 << I40E_GLNVM_ULD_CONF_PCIRTL_DONE_SHIFT)
+#define I40E_GLNVM_ULD_CONF_LCB_DONE_SHIFT 2
+#define I40E_GLNVM_ULD_CONF_LCB_DONE_MASK (0x1 << I40E_GLNVM_ULD_CONF_LCB_DONE_SHIFT)
+#define I40E_GLNVM_ULD_CONF_CORE_DONE_SHIFT 3
+#define I40E_GLNVM_ULD_CONF_CORE_DONE_MASK (0x1 << I40E_GLNVM_ULD_CONF_CORE_DONE_SHIFT)
+#define I40E_GLNVM_ULD_CONF_GLOBAL_DONE_SHIFT 4
+#define I40E_GLNVM_ULD_CONF_GLOBAL_DONE_MASK (0x1 << I40E_GLNVM_ULD_CONF_GLOBAL_DONE_SHIFT)
+#define I40E_GLNVM_ULD_CONF_POR_DONE_SHIFT 5
+#define I40E_GLNVM_ULD_CONF_POR_DONE_MASK (0x1 << I40E_GLNVM_ULD_CONF_POR_DONE_SHIFT)
+#define I40E_GLNVM_ULD_CONF_PCIE_ANA_DONE_SHIFT 6
+#define I40E_GLNVM_ULD_CONF_PCIE_ANA_DONE_MASK (0x1 << I40E_GLNVM_ULD_CONF_PCIE_ANA_DONE_SHIFT)
+#define I40E_GLNVM_ULD_CONF_PHY_ANA_DONE_SHIFT 7
+#define I40E_GLNVM_ULD_CONF_PHY_ANA_DONE_MASK (0x1 << I40E_GLNVM_ULD_CONF_PHY_ANA_DONE_SHIFT)
+#define I40E_GLNVM_ULD_CONF_EMP_DONE_SHIFT 8
+#define I40E_GLNVM_ULD_CONF_EMP_DONE_MASK (0x1 << I40E_GLNVM_ULD_CONF_EMP_DONE_SHIFT)
+#define I40E_GLNVM_ULD_CONF_PCIALT_DONE_SHIFT 9
+#define I40E_GLNVM_ULD_CONF_PCIALT_DONE_MASK (0x1 << I40E_GLNVM_ULD_CONF_PCIALT_DONE_SHIFT)
+
#define I40E_GLPCI_BYTCTH 0x0009C484
#define I40E_GLPCI_BYTCTH_PCI_COUNT_BW_BCT_SHIFT 0
#define I40E_GLPCI_BYTCTH_PCI_COUNT_BW_BCT_MASK (0xFFFFFFFF << I40E_GLPCI_BYTCTH_PCI_COUNT_BW_BCT_SHIFT)
--
1.8.3.1
^ permalink raw reply related
* [net-next 05/15] i40e: Bump version
From: Jeff Kirsher @ 2014-01-07 9:32 UTC (permalink / raw)
To: davem
Cc: Catherine Sullivan, netdev, gospo, sassmann, Jesse Brandeburg,
Jeff Kirsher
In-Reply-To: <1389087149-27962-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Catherine Sullivan <catherine.sullivan@intel.com>
Version update to 0.3.25-k
Signed-off-by: Catherine Sullivan <catherine.sullivan@intel.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 2a42470..f736c44 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -39,7 +39,7 @@ static const char i40e_driver_string[] =
#define DRV_VERSION_MAJOR 0
#define DRV_VERSION_MINOR 3
-#define DRV_VERSION_BUILD 14
+#define DRV_VERSION_BUILD 25
#define DRV_VERSION __stringify(DRV_VERSION_MAJOR) "." \
__stringify(DRV_VERSION_MINOR) "." \
__stringify(DRV_VERSION_BUILD) DRV_KERN
--
1.8.3.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox