* [PATCH v2 2/2] net/benet: Make lancer_wait_ready() static
From: Gavin Shan @ 2013-10-28 2:12 UTC (permalink / raw)
To: netdev; +Cc: Sathya.Perla, davem, Gavin Shan
In-Reply-To: <1382926367-14968-1-git-send-email-shangw@linux.vnet.ibm.com>
The function needn't to be public, so to make it as static.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
---
drivers/net/ethernet/emulex/benet/be_cmds.c | 2 +-
drivers/net/ethernet/emulex/benet/be_cmds.h | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c b/drivers/net/ethernet/emulex/benet/be_cmds.c
index c08fd32..c30ab8f 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.c
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.c
@@ -522,7 +522,7 @@ static u16 be_POST_stage_get(struct be_adapter *adapter)
return sem & POST_STAGE_MASK;
}
-int lancer_wait_ready(struct be_adapter *adapter)
+static int lancer_wait_ready(struct be_adapter *adapter)
{
#define SLIPORT_READY_TIMEOUT 30
u32 sliport_status;
diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.h b/drivers/net/ethernet/emulex/benet/be_cmds.h
index 108ca8a..dd522b0 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.h
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.h
@@ -1983,7 +1983,6 @@ extern int be_cmd_get_ext_fat_capabilites(struct be_adapter *adapter,
extern int be_cmd_set_ext_fat_capabilites(struct be_adapter *adapter,
struct be_dma_mem *cmd,
struct be_fat_conf_params *cfgs);
-extern int lancer_wait_ready(struct be_adapter *adapter);
extern int lancer_physdev_ctrl(struct be_adapter *adapter, u32 mask);
extern int lancer_initiate_dump(struct be_adapter *adapter);
extern bool dump_present(struct be_adapter *adapter);
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 1/2] net/benet: Remove interface type
From: Gavin Shan @ 2013-10-28 2:12 UTC (permalink / raw)
To: netdev; +Cc: Sathya.Perla, davem, Gavin Shan
The interrupt type, which is being traced by "struct be_adapter::
if_type", isn't used currently. So we can remove that safely
according to Sathya's comments.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
---
drivers/net/ethernet/emulex/benet/be.h | 1 -
drivers/net/ethernet/emulex/benet/be_main.c | 5 -----
2 files changed, 6 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be.h b/drivers/net/ethernet/emulex/benet/be.h
index db02023..5e195e7 100644
--- a/drivers/net/ethernet/emulex/benet/be.h
+++ b/drivers/net/ethernet/emulex/benet/be.h
@@ -437,7 +437,6 @@ struct be_adapter {
u32 rx_fc; /* Rx flow control */
u32 tx_fc; /* Tx flow control */
bool stats_cmd_sent;
- u32 if_type;
struct {
u32 size;
u32 total_size;
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index 2c38cc4..992c9ee 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -3960,11 +3960,6 @@ static int be_roce_map_pci_bars(struct be_adapter *adapter)
static int be_map_pci_bars(struct be_adapter *adapter)
{
u8 __iomem *addr;
- u32 sli_intf;
-
- pci_read_config_dword(adapter->pdev, SLI_INTF_REG_OFFSET, &sli_intf);
- adapter->if_type = (sli_intf & SLI_INTF_IF_TYPE_MASK) >>
- SLI_INTF_IF_TYPE_SHIFT;
if (BEx_chip(adapter) && be_physfn(adapter)) {
adapter->csr = pci_iomap(adapter->pdev, 2, 0);
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH net] xen-netback: use jiffies_64 value to calculate credit timeout
From: annie li @ 2013-10-28 2:36 UTC (permalink / raw)
To: Wei Liu; +Cc: xen-devel, netdev, david.vrabel, jbeulich, Ian Campbell,
Jason Luan
In-Reply-To: <1382872313-11675-1-git-send-email-wei.liu2@citrix.com>
On 2013-10-27 19:11, Wei Liu wrote:
> time_after_eq() only works if the delta is < MAX_ULONG/2.
>
> For a 32bit Dom0, if netfront sends packets at a very low rate, the time
> between subsequent calls to tx_credit_exceeded() may exceed MAX_ULONG/2
> and the test for timer_after_eq() will be incorrect. Credit will not be
> replenished and the guest may become unable to send packets (e.g., if
> prior to the long gap, all credit was exhausted).
>
> Use jiffies_64 variant to mitigate this problem for 32bit Dom0.
>
> Suggested-by: Jan Beulich <jbeulich@suse.com>
> Suggested-by: David Vrabel <david.vrabel@citrix.com>
> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Jason Luan <jianhai.luan@oracle.com>
> ---
> drivers/net/xen-netback/common.h | 1 +
> drivers/net/xen-netback/interface.c | 4 ++--
> drivers/net/xen-netback/netback.c | 13 ++++++-------
> 3 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
> index 5715318..400fea1 100644
> --- a/drivers/net/xen-netback/common.h
> +++ b/drivers/net/xen-netback/common.h
> @@ -163,6 +163,7 @@ struct xenvif {
> unsigned long credit_usec;
> unsigned long remaining_credit;
> struct timer_list credit_timeout;
> + u64 credit_window_start;
>
> /* Statistics */
> unsigned long rx_gso_checksum_fixup;
> diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
> index 01bb854..8c45b63 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -312,8 +312,8 @@ struct xenvif *xenvif_alloc(struct device *parent, domid_t domid,
> vif->credit_bytes = vif->remaining_credit = ~0UL;
> vif->credit_usec = 0UL;
> init_timer(&vif->credit_timeout);
> - /* Initialize 'expires' now: it's used to track the credit window. */
> - vif->credit_timeout.expires = jiffies;
> + /* credit window is tracked in credit_window_start */
> + vif->credit_window_start = get_jiffies_64();
>
> dev->netdev_ops = &xenvif_netdev_ops;
> dev->hw_features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_TSO;
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index f3e591c..1bc0688 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -1185,18 +1185,17 @@ out:
>
> static bool tx_credit_exceeded(struct xenvif *vif, unsigned size)
> {
> - unsigned long now = jiffies;
> - unsigned long next_credit =
> - vif->credit_timeout.expires +
> - msecs_to_jiffies(vif->credit_usec / 1000);
> + u64 now = get_jiffies_64();
> + u64 next_credit = vif->credit_window_start +
> + (u64)msecs_to_jiffies(vif->credit_usec / 1000);
You simply replace "credit_timeout.expires" with
"vif->credit_window_start" here, and never update
"vif->credit_window_start" in following code.
>
> /* Timer could already be pending in rare cases. */
> if (timer_pending(&vif->credit_timeout))
> return true;
>
> /* Passed the point where we can replenish credit? */
> - if (time_after_eq(now, next_credit)) {
> - vif->credit_timeout.expires = now;
> + if (time_after_eq64(now, next_credit)) {
> + vif->credit_timeout.expires = (unsigned long)now;
updates credit_window_start as following,
vif->credit_window_start = (unsigned long)now;
> tx_add_credit(vif);
> }
>
> @@ -1207,7 +1206,7 @@ static bool tx_credit_exceeded(struct xenvif *vif, unsigned size)
> vif->credit_timeout.function =
> tx_credit_callback;
> mod_timer(&vif->credit_timeout,
> - next_credit);
> + (unsigned long)next_credit);
vif->credit_timeout.expires is unsigned long, and this still causes
original issue on 32bit system, which works well on 64bit. Or rewriting
code to avoid uses of vif->credit_timeout.expires, but it is complex.
BTW, I prefer Luan's patch which is simple and clear.
Thanks
Annie
^ permalink raw reply
* Re: [Xen-devel] [PATCH net] xen-netback: use jiffies_64 value to calculate credit timeout
From: annie li @ 2013-10-28 2:58 UTC (permalink / raw)
To: Wei Liu; +Cc: Ian Campbell, netdev, xen-devel, david.vrabel, jbeulich,
Jason Luan
In-Reply-To: <526DCDB8.1080908@oracle.com>
On 2013-10-28 10:36, annie li wrote:
>
> On 2013-10-27 19:11, Wei Liu wrote:
>> time_after_eq() only works if the delta is < MAX_ULONG/2.
>>
>> For a 32bit Dom0, if netfront sends packets at a very low rate, the time
>> between subsequent calls to tx_credit_exceeded() may exceed MAX_ULONG/2
>> and the test for timer_after_eq() will be incorrect. Credit will not be
>> replenished and the guest may become unable to send packets (e.g., if
>> prior to the long gap, all credit was exhausted).
>>
>> Use jiffies_64 variant to mitigate this problem for 32bit Dom0.
>>
>> Suggested-by: Jan Beulich <jbeulich@suse.com>
>> Suggested-by: David Vrabel <david.vrabel@citrix.com>
>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
>> Cc: Ian Campbell <ian.campbell@citrix.com>
>> Cc: Jason Luan <jianhai.luan@oracle.com>
>> ---
>> drivers/net/xen-netback/common.h | 1 +
>> drivers/net/xen-netback/interface.c | 4 ++--
>> drivers/net/xen-netback/netback.c | 13 ++++++-------
>> 3 files changed, 9 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/net/xen-netback/common.h
>> b/drivers/net/xen-netback/common.h
>> index 5715318..400fea1 100644
>> --- a/drivers/net/xen-netback/common.h
>> +++ b/drivers/net/xen-netback/common.h
>> @@ -163,6 +163,7 @@ struct xenvif {
>> unsigned long credit_usec;
>> unsigned long remaining_credit;
>> struct timer_list credit_timeout;
>> + u64 credit_window_start;
>> /* Statistics */
>> unsigned long rx_gso_checksum_fixup;
>> diff --git a/drivers/net/xen-netback/interface.c
>> b/drivers/net/xen-netback/interface.c
>> index 01bb854..8c45b63 100644
>> --- a/drivers/net/xen-netback/interface.c
>> +++ b/drivers/net/xen-netback/interface.c
>> @@ -312,8 +312,8 @@ struct xenvif *xenvif_alloc(struct device
>> *parent, domid_t domid,
>> vif->credit_bytes = vif->remaining_credit = ~0UL;
>> vif->credit_usec = 0UL;
>> init_timer(&vif->credit_timeout);
>> - /* Initialize 'expires' now: it's used to track the credit
>> window. */
>> - vif->credit_timeout.expires = jiffies;
>> + /* credit window is tracked in credit_window_start */
>> + vif->credit_window_start = get_jiffies_64();
>> dev->netdev_ops = &xenvif_netdev_ops;
>> dev->hw_features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_TSO;
>> diff --git a/drivers/net/xen-netback/netback.c
>> b/drivers/net/xen-netback/netback.c
>> index f3e591c..1bc0688 100644
>> --- a/drivers/net/xen-netback/netback.c
>> +++ b/drivers/net/xen-netback/netback.c
>> @@ -1185,18 +1185,17 @@ out:
>> static bool tx_credit_exceeded(struct xenvif *vif, unsigned size)
>> {
>> - unsigned long now = jiffies;
>> - unsigned long next_credit =
>> - vif->credit_timeout.expires +
>> - msecs_to_jiffies(vif->credit_usec / 1000);
>> + u64 now = get_jiffies_64();
>> + u64 next_credit = vif->credit_window_start +
>> + (u64)msecs_to_jiffies(vif->credit_usec / 1000);
>
> You simply replace "credit_timeout.expires" with
> "vif->credit_window_start" here, and never update
> "vif->credit_window_start" in following code.
>
>> /* Timer could already be pending in rare cases. */
>> if (timer_pending(&vif->credit_timeout))
>> return true;
>> /* Passed the point where we can replenish credit? */
>> - if (time_after_eq(now, next_credit)) {
>> - vif->credit_timeout.expires = now;
>> + if (time_after_eq64(now, next_credit)) {
>> + vif->credit_timeout.expires = (unsigned long)now;
>
> updates credit_window_start as following,
> vif->credit_window_start = (unsigned long)now;
both credit_window_start and credit_timeout.expires need to be updated
here,
vif->credit_window_start = (unsigned long)now;
vif->credit_timeout.expires = (unsigned long)now;
>
>> tx_add_credit(vif);
>> }
>> @@ -1207,7 +1206,7 @@ static bool tx_credit_exceeded(struct xenvif
>> *vif, unsigned size)
>> vif->credit_timeout.function =
>> tx_credit_callback;
>> mod_timer(&vif->credit_timeout,
>> - next_credit);
>> + (unsigned long)next_credit);
>
> vif->credit_timeout.expires is unsigned long, and this still causes
> original issue on 32bit system, which works well on 64bit. Or
> rewriting code to avoid uses of vif->credit_timeout.expires, but it is
> complex.
My understanding here is wrong, please ignore this.
Thanks
Annie
^ permalink raw reply
* Re: [PATCH net-next v2 0/5] bonding: patchset for rcu use in bonding
From: Ding Tianhong @ 2013-10-28 3:02 UTC (permalink / raw)
To: Veaceslav Falico
Cc: Jay Vosburgh, Andy Gospodarek, David S. Miller,
Nikolay Aleksandrov, Netdev
In-Reply-To: <20131028013428.GC11209@redhat.com>
On 2013/10/28 9:34, Veaceslav Falico wrote:
> On Mon, Oct 28, 2013 at 09:15:52AM +0800, Ding Tianhong wrote:
>> On 2013/10/28 6:53, Veaceslav Falico wrote:
>>> On Thu, Oct 24, 2013 at 11:08:35AM +0800, Ding Tianhong wrote:
>>>> Hi:
>>>>
>>>> The slave list will add and del by bond_master_upper_dev_link() and bond_upper_dev_unlink(),
>>>> which will call call_netdevice_notifiers(), even it is safe to call it in write bond lock now,
>>>> but we can't sure that whether it is safe later, because other drivers may deal NETDEV_CHANGEUPPER
>>>> in sleep way, so I didn't admit move the bond_upper_dev_unlink() in write bond lock.
>>>>
>>>> now the bond_for_each_slave only protect by rtnl_lock(), maybe use bond_for_each_slave_rcu is a good
>>>> way to protect slave list for bond, but as a system slow path, it is no need to transform bond_for_each_slave()
>>>> to bond_for_each_slave_rcu() in slow path, so in the patchset, I will remove the unused read bond lock
>>>> for monitor function, maybe it is a better way, I will wait to accept any relay for it.
>>>>
>>>> Thanks for the Veaceslav Falico opinion.
>>>>
>>>> v2: add and modify commit for patchset and patch, it will be the first step for the whole patchset.
>>>>
>>>> Ding Tianhong (5):
>>>> bonding: remove bond read lock for bond_mii_monitor()
>>>> bonding: remove bond read lock for bond_alb_monitor()
>>>> bonding: remove bond read lock for bond_loadbalance_arp_mon()
>>>> bonding: remove bond read lock for bond_activebackup_arp_mon()
>>>
>>> This patch introduces a regression by boot-test with active backup mode:
>>>
>>> bond_activebackup_arp_mon() is already not holding the bond->lock, however
>>> it might call bond_change_active_slave(), which does (in case of new_active):
>>>
>>> 912 write_unlock_bh(&bond->curr_slave_lock);
>>> 913 read_unlock(&bond->lock);
>>> 914 915 call_netdevice_notifiers(NETDEV_BONDING_FAILOVER, bond->dev);
>>> 916 if (should_notify_peers)
>>> 917 call_netdevice_notifiers(NETDEV_NOTIFY_PEERS,
>>> 918 bond->dev);
>>> 919 920 read_lock(&bond->lock);
>>> 921 write_lock_bh(&bond->curr_slave_lock);
>>>
>>> so it drops the bond->lock (which wasn't taken previously), and then takes
>>> it (without anyone dropping it afterwards).
>>>
>>> I don't know how to fix it - cause a lot of other callers already take it,
>>> and we can't just drop them (we'd race), and we can't remove it here (cause
>>> we can't call notifiers while atomic).
>>>
>>> Which begs the question - was this patchset tested at all?
>>>
>>> [ 21.796823] =====================================
>>> [ 21.796823] [ BUG: bad unlock balance detected! ]
> ... snip ...
>>
>> Hi David:
>> yes, exactly I miss it and make a mistake, the bond_select_active_slave is still have the protect problem and
>> need to be processed, I miss it, sorry, I will send a patch to fix the bug soon.
>>
>> Hi Veaceslav:
>> sorry about the commit, I will pay more attention to the commit and test, thanks for your advise and report the bug,
>> I have to admin that I was too careless.
>
> I'll ask you once again, even though it seems that my NACK doesn't block
> the patchset - try writing commit messages that actually describe why and
> how you do it.
>
> It's, actually, not only for the reviewers - it's also really good for you
> - cause while writing the commit log you also understand a lot more what
> are you doing, and might spot some corner cases (like this one).
>
> Sorry for being negative, however it costs me *much* more time to review
> patches without proper commit messages. I've done it once, twice, several
> times more - but that's it, I refuse to spend my time on your skipped
> homework.
>
> It might also help to split patches into really small steps - as in - do
> only one thing at a time, and describe it. This will help evade bugs *a
> lot*. It also helps people who'll bisect it, bugfix it and review it -
> because every patch will be a small, well-documented change, instead of a
> chunk of code with a description 'lets remove bond->lock'.
>
> Thank you and hope that helps.
>
sincere receiving all opinions.
thanks.
Regards.
Ding
>>
>>
>>
>>
>>>>
>>>> --
>>>> 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
* Re: [PATCH net-next v2 0/5] bonding: patchset for rcu use in bonding
From: David Miller @ 2013-10-28 4:00 UTC (permalink / raw)
To: vfalico; +Cc: dingtianhong, fubar, andy, nikolay, netdev
In-Reply-To: <20131027221027.GA11209@redhat.com>
From: Veaceslav Falico <vfalico@redhat.com>
Date: Sun, 27 Oct 2013 23:10:27 +0100
> On Sun, Oct 27, 2013 at 05:44:58PM -0400, David Miller wrote:
>>I would have preferred that he did all of this in the initial 0/N
>>patch posting, but I can't defer forever.
>
> Maybe I'm too picky. Anyway - understood, thanks.
I'm happy to revert his changes if you find real problems with them,
but I'd rather you two work more closely together in the future so I
don't have to break the deadlock like I did this time.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next v2 0/5] bonding: patchset for rcu use in bonding
From: David Miller @ 2013-10-28 4:01 UTC (permalink / raw)
To: vfalico; +Cc: dingtianhong, fubar, andy, nikolay, netdev
In-Reply-To: <20131027225317.GB11209@redhat.com>
From: Veaceslav Falico <vfalico@redhat.com>
Date: Sun, 27 Oct 2013 23:53:17 +0100
> This patch introduces a regression by boot-test with active backup
> mode:
Ok I'm reverting.
^ permalink raw reply
* Re: [PATCH v2] pkt_sched: fq: clear time_next_packet for reused flows
From: David Miller @ 2013-10-28 4:19 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1382916403.4045.17.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 27 Oct 2013 16:26:43 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> When a socket is freed/reallocated, we need to clear time_next_packet
> or else we can inherit a prior value and delay first packets of the
> new flow.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2013-10-28 4:23 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Somnath Kotur, Sathya Perla
[-- Attachment #1: Type: text/plain, Size: 4320 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/emulex/benet/be.h between commit e9e2a904ef0a
("be2net: Warn users of possible broken functionality on BE2 cards with
very old FW versions with latest driver") from the net tree and commit
6384a4d0dcf9 ("be2net: add support for ndo_busy_poll") from the net-next
tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/net/ethernet/emulex/benet/be.h
index c99dac6a9ddf,b2765ebb0268..000000000000
--- a/drivers/net/ethernet/emulex/benet/be.h
+++ b/drivers/net/ethernet/emulex/benet/be.h
@@@ -696,23 -733,114 +733,123 @@@ static inline int qnq_async_evt_rcvd(st
return adapter->flags & BE_FLAGS_QNQ_ASYNC_EVT_RCVD;
}
+static inline int fw_major_num(const char *fw_ver)
+{
+ int fw_major = 0;
+
+ sscanf(fw_ver, "%d.", &fw_major);
+
+ return fw_major;
+}
+
- extern void be_cq_notify(struct be_adapter *adapter, u16 qid, bool arm,
- u16 num_popped);
- extern void be_link_status_update(struct be_adapter *adapter, u8 link_status);
- extern void be_parse_stats(struct be_adapter *adapter);
- extern int be_load_fw(struct be_adapter *adapter, u8 *func);
- extern bool be_is_wol_supported(struct be_adapter *adapter);
- extern bool be_pause_supported(struct be_adapter *adapter);
- extern u32 be_get_fw_log_level(struct be_adapter *adapter);
+ #ifdef CONFIG_NET_RX_BUSY_POLL
+ static inline bool be_lock_napi(struct be_eq_obj *eqo)
+ {
+ bool status = true;
+
+ spin_lock(&eqo->lock); /* BH is already disabled */
+ if (eqo->state & BE_EQ_LOCKED) {
+ WARN_ON(eqo->state & BE_EQ_NAPI);
+ eqo->state |= BE_EQ_NAPI_YIELD;
+ status = false;
+ } else {
+ eqo->state = BE_EQ_NAPI;
+ }
+ spin_unlock(&eqo->lock);
+ return status;
+ }
+
+ static inline void be_unlock_napi(struct be_eq_obj *eqo)
+ {
+ spin_lock(&eqo->lock); /* BH is already disabled */
+
+ WARN_ON(eqo->state & (BE_EQ_POLL | BE_EQ_NAPI_YIELD));
+ eqo->state = BE_EQ_IDLE;
+
+ spin_unlock(&eqo->lock);
+ }
+
+ static inline bool be_lock_busy_poll(struct be_eq_obj *eqo)
+ {
+ bool status = true;
+
+ spin_lock_bh(&eqo->lock);
+ if (eqo->state & BE_EQ_LOCKED) {
+ eqo->state |= BE_EQ_POLL_YIELD;
+ status = false;
+ } else {
+ eqo->state |= BE_EQ_POLL;
+ }
+ spin_unlock_bh(&eqo->lock);
+ return status;
+ }
+
+ static inline void be_unlock_busy_poll(struct be_eq_obj *eqo)
+ {
+ spin_lock_bh(&eqo->lock);
+
+ WARN_ON(eqo->state & (BE_EQ_NAPI));
+ eqo->state = BE_EQ_IDLE;
+
+ spin_unlock_bh(&eqo->lock);
+ }
+
+ static inline void be_enable_busy_poll(struct be_eq_obj *eqo)
+ {
+ spin_lock_init(&eqo->lock);
+ eqo->state = BE_EQ_IDLE;
+ }
+
+ static inline void be_disable_busy_poll(struct be_eq_obj *eqo)
+ {
+ local_bh_disable();
+
+ /* It's enough to just acquire napi lock on the eqo to stop
+ * be_busy_poll() from processing any queueus.
+ */
+ while (!be_lock_napi(eqo))
+ mdelay(1);
+
+ local_bh_enable();
+ }
+
+ #else /* CONFIG_NET_RX_BUSY_POLL */
+
+ static inline bool be_lock_napi(struct be_eq_obj *eqo)
+ {
+ return true;
+ }
+
+ static inline void be_unlock_napi(struct be_eq_obj *eqo)
+ {
+ }
+
+ static inline bool be_lock_busy_poll(struct be_eq_obj *eqo)
+ {
+ return false;
+ }
+
+ static inline void be_unlock_busy_poll(struct be_eq_obj *eqo)
+ {
+ }
+
+ static inline void be_enable_busy_poll(struct be_eq_obj *eqo)
+ {
+ }
+
+ static inline void be_disable_busy_poll(struct be_eq_obj *eqo)
+ {
+ }
+ #endif /* CONFIG_NET_RX_BUSY_POLL */
+
+ void be_cq_notify(struct be_adapter *adapter, u16 qid, bool arm,
+ u16 num_popped);
+ void be_link_status_update(struct be_adapter *adapter, u8 link_status);
+ void be_parse_stats(struct be_adapter *adapter);
+ int be_load_fw(struct be_adapter *adapter, u8 *func);
+ bool be_is_wol_supported(struct be_adapter *adapter);
+ bool be_pause_supported(struct be_adapter *adapter);
+ u32 be_get_fw_log_level(struct be_adapter *adapter);
int be_update_queues(struct be_adapter *adapter);
int be_poll(struct napi_struct *napi, int budget);
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] inet: restore gso for vxlan
From: David Miller @ 2013-10-28 4:25 UTC (permalink / raw)
To: eric.dumazet; +Cc: ast, netdev
In-Reply-To: <1382923096.13037.10.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 27 Oct 2013 18:18:16 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> Alexei reported a performance regression on vxlan, caused
> by commit 3347c9602955 "ipv4: gso: make inet_gso_segment() stackable"
>
> GSO vxlan packets were not properly segmented, adding IP fragments
> while they were not expected.
>
> Rename 'bool tunnel' to 'bool encap', and add a new boolean
> to express the fact that UDP should be fragmented.
> This fragmentation is triggered by skb->encapsulation being set.
>
> Remove a "skb->encapsulation = 1" added in above commit,
> as its not needed, as frags inherit skb->frag from original
> GSO skb.
>
> Reported-by: Alexei Starovoitov <ast@plumgrid.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Tested-by: Alexei Starovoitov <ast@plumgrid.com>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH 2/8] farsync: Fix confusion about DMA address and buffer offset types
From: David Miller @ 2013-10-28 4:26 UTC (permalink / raw)
To: ben; +Cc: kevin.curtis, linux-kernel, netdev
In-Reply-To: <1382910704.2994.46.camel@deadeye.wl.decadent.org.uk>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Sun, 27 Oct 2013 21:51:44 +0000
> - dbg(DBG_TX, "In fst_tx_dma %p %p %d\n", skb, mem, len);
> + dbg(DBG_TX, "In fst_tx_dma %x %x %d\n", (u32)skb, mem, len);
Please use %p for the skb pointer instead of casting it (which btw
will introduce a warning on 64-bit).
^ permalink raw reply
* Re: [PATCH 7/8] rds: Pass pointers to virt_to_page(), not integers
From: David Miller @ 2013-10-28 4:26 UTC (permalink / raw)
To: ben; +Cc: venkat.x.venkatsubra, linux-kernel, rds-devel, netdev
In-Reply-To: <1382910856.2994.51.camel@deadeye.wl.decadent.org.uk>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Sun, 27 Oct 2013 21:54:16 +0000
> Most architectures define virt_to_page() as a macro that casts its
> argument such that an argument of type unsigned long will be accepted
> without complaint. However, the proper type is void *, and passing
> unsigned long results in a warning on MIPS.
>
> Compile-tested only.
>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
This looks fine:
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH 1/3] vxlan: silence one build warning
From: David Miller @ 2013-10-28 4:38 UTC (permalink / raw)
To: stephen; +Cc: zwu.kernel, netdev, linux-kernel, wuzhy
In-Reply-To: <20131025084134.6cfa153a@samsung-9>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Fri, 25 Oct 2013 08:41:34 -0700
> I would rather not fix the warning this way since it risks masking
> later bugs if this code ever changes.
But this is suboptimally coded, and is asking for the warning.
Anything returning a pointer by reference is asking for trouble
in my opinion.
The correct thing to do is to make create_v{4,6}_sock() return
the "struct socket *" as an error pointer.
No more ambiguous initializations, no more warnings.
^ permalink raw reply
* Re: [PATCH 2/3] net, datagram: fix the uncorrect comment in zerocopy_sg_from_iovec()
From: David Miller @ 2013-10-28 4:39 UTC (permalink / raw)
To: zwu.kernel; +Cc: netdev, linux-kernel, wuzhy
In-Reply-To: <1382687360-27794-2-git-send-email-zwu.kernel@gmail.com>
"uncorrect" is not a word, you mean to say "incorrect".
Same goes for patch #3.
^ permalink raw reply
* Re: Big performance loss from 3.4.63 to 3.10.13 when routing ipv4
From: David Miller @ 2013-10-28 4:43 UTC (permalink / raw)
To: steffen.klassert; +Cc: eric.dumazet, linux, hannes, netdev, klassert
In-Reply-To: <20131025092043.GD31491@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Fri, 25 Oct 2013 11:20:43 +0200
> On Fri, Oct 25, 2013 at 01:50:28AM -0700, Eric Dumazet wrote:
>>
>> 32768 as the default seems fine to me
>>
>> 448 bytes per dst -> thats less than 30 Mbytes of memory if we hit 65536
>> dst.
>>
>
> Ok, I'll add the patch below to to the ipsec tree if everyone is fine
> with that threshold.
No objections from me.
^ permalink raw reply
* Re: [PATCH 2/8] farsync: Fix confusion about DMA address and buffer offset types
From: Ben Hutchings @ 2013-10-28 4:51 UTC (permalink / raw)
To: David Miller; +Cc: kevin.curtis, linux-kernel, netdev
In-Reply-To: <20131028.002627.2095063739326406659.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 743 bytes --]
On Mon, 2013-10-28 at 00:26 -0400, David Miller wrote:
> From: Ben Hutchings <ben@decadent.org.uk>
> Date: Sun, 27 Oct 2013 21:51:44 +0000
>
> > - dbg(DBG_TX, "In fst_tx_dma %p %p %d\n", skb, mem, len);
> > + dbg(DBG_TX, "In fst_tx_dma %x %x %d\n", (u32)skb, mem, len);
>
> Please use %p for the skb pointer instead of casting it (which btw
> will introduce a warning on 64-bit).
skb is the DMA address of the data in the sk_buff. Yes, this is really
unusual naming.
Ben.
--
Ben Hutchings
[W]e found...that it wasn't as easy to get programs right as we had thought.
... I realized that a large part of my life from then on was going to be spent
in finding mistakes in my own programs. - Maurice Wilkes, 1949
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] veth: extend features to support tunneling
From: David Miller @ 2013-10-28 4:58 UTC (permalink / raw)
To: eric.dumazet; +Cc: ast, edumazet, stephen, netdev
In-Reply-To: <1382750703.4032.32.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 25 Oct 2013 18:25:03 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> While investigating on a recent vxlan regression, I found veth
> was using a zero features set for vxlan tunnels.
>
> We have to segment GSO frames, copy the payload, and do the checksum.
>
> This patch brings a ~200% performance increase
>
> We probably have to add hw_enc_features support
> on other virtual devices.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next] tcp: gso: fix truesize tracking
From: David Miller @ 2013-10-28 4:58 UTC (permalink / raw)
To: eric.dumazet; +Cc: ast, edumazet, stephen, netdev
In-Reply-To: <1382747177.4032.21.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 25 Oct 2013 17:26:17 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> commit 6ff50cd55545 ("tcp: gso: do not generate out of order packets")
> had an heuristic that can trigger a warning in skb_try_coalesce(),
> because skb->truesize of the gso segments were exactly set to mss.
>
> This breaks the requirement that
>
> skb->truesize >= skb->len + truesizeof(struct sk_buff);
>
> It can trivially be reproduced by :
>
> ifconfig lo mtu 1500
> ethtool -K lo tso off
> netperf
>
> As the skbs are looped into the TCP networking stack, skb_try_coalesce()
> warns us of these skb under-estimating their truesize.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Alexei Starovoitov <ast@plumgrid.com>
> ---
> Based on net-next but applies as well on net tree with some fuzz.
>
> David, we might backport this one to 3.12 and stable later, I let you
> decide.
I'm still thinking about what to do with this one.
^ permalink raw reply
* Re: [PATCH 2/8] farsync: Fix confusion about DMA address and buffer offset types
From: David Miller @ 2013-10-28 4:59 UTC (permalink / raw)
To: ben; +Cc: kevin.curtis, linux-kernel, netdev
In-Reply-To: <1382935885.3524.38.camel@deadeye.wl.decadent.org.uk>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Mon, 28 Oct 2013 04:51:25 +0000
> On Mon, 2013-10-28 at 00:26 -0400, David Miller wrote:
>> From: Ben Hutchings <ben@decadent.org.uk>
>> Date: Sun, 27 Oct 2013 21:51:44 +0000
>>
>> > - dbg(DBG_TX, "In fst_tx_dma %p %p %d\n", skb, mem, len);
>> > + dbg(DBG_TX, "In fst_tx_dma %x %x %d\n", (u32)skb, mem, len);
>>
>> Please use %p for the skb pointer instead of casting it (which btw
>> will introduce a warning on 64-bit).
>
> skb is the DMA address of the data in the sk_buff. Yes, this is really
> unusual naming.
Hmmm, Ok then I guess. :-/
^ permalink raw reply
* Re: [PATCH v2 0/3] sctp: do some clean up and fix comments
From: David Miller @ 2013-10-28 5:02 UTC (permalink / raw)
To: wangweidong1; +Cc: nhorman, vyasevich, dingtianhong, linux-sctp, netdev
In-Reply-To: <1382774792-13440-1-git-send-email-wangweidong1@huawei.com>
From: Wang Weidong <wangweidong1@huawei.com>
Date: Sat, 26 Oct 2013 16:06:29 +0800
> This patch series includes some comments fix, merge tow if-statements,
> remove the repeat initialize with 0.
>
> v1 -> v2:
> - patch1: combine two comment typos fix patches into one,
> as suggested by Vlad, and add his ACK.
> - patch2: add Vlad's ACK.
> - patch3: line up 2 parts of 'if' statements, as suggested by Vlad.
> fix some comment typos, as suggested by Sergei.
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH net-next 2/3] tipc: message reassembly using fragment chain
From: David Miller @ 2013-10-28 5:07 UTC (permalink / raw)
To: jon.maloy; +Cc: netdev, tipc-discussion
In-Reply-To: <1382812863-23571-3-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Sat, 26 Oct 2013 14:41:02 -0400
> + int ret = tipc_link_recv_fragment(
> + &node->bclink.reasm_head,
> + &node->bclink.reasm_tail,
> + &buf);
This is not the correct way to indent a function call that spans
multiple lines. In such a situation the arguments that appear
on the second and subsequent lines must start at the first column
after the openning parenthesis of the function call.
Like this:
func(a, b, c,
d, e, f);
Please audit this in your entire set of patches and resubmit,
thanks.
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
^ permalink raw reply
* Re: [virtio-net] BUG: sleeping function called from invalid context at kernel/mutex.c:616
From: Jason Wang @ 2013-10-28 5:44 UTC (permalink / raw)
To: Fengguang Wu; +Cc: netdev, linux-kernel, virtualization
In-Reply-To: <20131023232033.GA7404@localhost>
On 10/24/2013 07:20 AM, Fengguang Wu wrote:
> Yes it reduces the sleeping function bug:
>
> /kernel/x86_64-lkp-CONFIG_SCSI_DEBUG/7c4ed2767afb813493b0a8fb18d666cd44550963
>
> +------------------------------------------------------------------------------------+-----------+--------------+--------------+
> | | v3.12-rc3 | 3ab098df35f8 | 7c4ed2767afb |
> +------------------------------------------------------------------------------------+-----------+--------------+--------------+
> | good_boots | 30 | 0 | 93 |
> | has_kernel_error_warning | 0 | 20 | 7 |
> | BUG:sleeping_function_called_from_invalid_context_at_kernel/mutex.c | 0 | 20 | |
> | INFO:rcu_sched_self-detected_stall_on_CPU(t=jiffies_g=c=q=) | 0 | 0 | 1 |
> | INFO:task_blocked_for_more_than_seconds | 0 | 0 | 2 |
> | INFO:NMI_handler(arch_trigger_all_cpu_backtrace_handler)took_too_long_to_run:msecs | 0 | 0 | 1 |
> | Kernel_panic-not_syncing:hung_task:blocked_tasks | 0 | 0 | 1 |
> | BUG:kernel_test_crashed | 0 | 0 | 3 |
> | BUG:kernel_test_hang | 0 | 0 | 1 |
> +------------------------------------------------------------------------------------+-----------+--------------+--------------+
>
> However I'll need to increase tests on v3.12-rc3 to make sure it's not
> the patch that added the other error messages.
>
> Thanks,
> Fengguang
Thanks, any more update on the result of v3.12-rc3 for this?
^ permalink raw reply
* Re: [PATCH 01/16] mac80211: fix TX device statistics for monitor interfaces
From: Kalle Valo @ 2013-10-28 5:53 UTC (permalink / raw)
To: Pali Rohár
Cc: Luciano Coelho, John W. Linville, Johannes Berg, David S. Miller,
linux-wireless, netdev, linux-kernel, freemangordon,
aaro.koskinen, pavel, sre, joni.lapilainen, David Gnedt
In-Reply-To: <1382819655-30430-2-git-send-email-pali.rohar@gmail.com>
Pali Rohár <pali.rohar@gmail.com> writes:
> From: David Gnedt <david.gnedt@davizone.at>
>
> Count TX packets and bytes also for monitor interfaces.
>
> Signed-of-by: David Gnedt <david.gnedt@davizone.at>
You should send mac80211 patches separately, not inside a wl1251 patchset.
--
Kalle Valo
^ permalink raw reply
* [PATCH v2 1/3] vxlan: silence one build warning
From: Zhi Yong Wu @ 2013-10-28 6:01 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, stephen, davem, Zhi Yong Wu
From: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
drivers/net/vxlan.c: In function ‘vxlan_sock_add’:
drivers/net/vxlan.c:2298:11: warning: ‘sock’ may be used uninitialized in this function [-Wmaybe-uninitialized]
drivers/net/vxlan.c:2275:17: note: ‘sock’ was declared here
LD drivers/net/built-in.o
Signed-off-by: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
---
drivers/net/vxlan.c | 31 ++++++++++++++-----------------
1 file changed, 14 insertions(+), 17 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 2ef5b62..019e1f4 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -2180,7 +2180,7 @@ static void vxlan_del_work(struct work_struct *work)
* could be used for both IPv4 and IPv6 communications, but
* users may set bindv6only=1.
*/
-static int create_v6_sock(struct net *net, __be16 port, struct socket **psock)
+static struct socket *create_v6_sock(struct net *net, __be16 port)
{
struct sock *sk;
struct socket *sock;
@@ -2193,7 +2193,7 @@ static int create_v6_sock(struct net *net, __be16 port, struct socket **psock)
rc = sock_create_kern(AF_INET6, SOCK_DGRAM, IPPROTO_UDP, &sock);
if (rc < 0) {
pr_debug("UDPv6 socket create failed\n");
- return rc;
+ return ERR_PTR(rc);
}
/* Put in proper namespace */
@@ -2208,28 +2208,27 @@ static int create_v6_sock(struct net *net, __be16 port, struct socket **psock)
pr_debug("bind for UDPv6 socket %pI6:%u (%d)\n",
&vxlan_addr.sin6_addr, ntohs(vxlan_addr.sin6_port), rc);
sk_release_kernel(sk);
- return rc;
+ return ERR_PTR(rc);
}
/* At this point, IPv6 module should have been loaded in
* sock_create_kern().
*/
BUG_ON(!ipv6_stub);
- *psock = sock;
/* Disable multicast loopback */
inet_sk(sk)->mc_loop = 0;
- return 0;
+ return sock;
}
#else
-static int create_v6_sock(struct net *net, __be16 port, struct socket **psock)
+static struct socket *create_v6_sock(struct net *net, __be16 port)
{
- return -EPFNOSUPPORT;
+ return ERR_PTR(-EPFNOSUPPORT);
}
#endif
-static int create_v4_sock(struct net *net, __be16 port, struct socket **psock)
+static struct socket *create_v4_sock(struct net *net, __be16 port)
{
struct sock *sk;
struct socket *sock;
@@ -2244,7 +2243,7 @@ static int create_v4_sock(struct net *net, __be16 port, struct socket **psock)
rc = sock_create_kern(AF_INET, SOCK_DGRAM, IPPROTO_UDP, &sock);
if (rc < 0) {
pr_debug("UDP socket create failed\n");
- return rc;
+ return ERR_PTR(rc);
}
/* Put in proper namespace */
@@ -2257,13 +2256,12 @@ static int create_v4_sock(struct net *net, __be16 port, struct socket **psock)
pr_debug("bind for UDP socket %pI4:%u (%d)\n",
&vxlan_addr.sin_addr, ntohs(vxlan_addr.sin_port), rc);
sk_release_kernel(sk);
- return rc;
+ return ERR_PTR(rc);
}
- *psock = sock;
/* Disable multicast loopback */
inet_sk(sk)->mc_loop = 0;
- return 0;
+ return sock;
}
/* Create new listen socket if needed */
@@ -2274,7 +2272,6 @@ static struct vxlan_sock *vxlan_socket_create(struct net *net, __be16 port,
struct vxlan_sock *vs;
struct socket *sock;
struct sock *sk;
- int rc = 0;
unsigned int h;
vs = kmalloc(sizeof(*vs), GFP_KERNEL);
@@ -2287,12 +2284,12 @@ static struct vxlan_sock *vxlan_socket_create(struct net *net, __be16 port,
INIT_WORK(&vs->del_work, vxlan_del_work);
if (ipv6)
- rc = create_v6_sock(net, port, &sock);
+ sock = create_v6_sock(net, port);
else
- rc = create_v4_sock(net, port, &sock);
- if (rc < 0) {
+ sock = create_v4_sock(net, port);
+ if (IS_ERR(sock)) {
kfree(vs);
- return ERR_PTR(rc);
+ return ERR_PTR(PTR_ERR(sock));
}
vs->sock = sock;
--
1.7.11.7
^ permalink raw reply related
* [PATCH v2 2/3] net, datagram: fix the incorrect comment in zerocopy_sg_from_iovec()
From: Zhi Yong Wu @ 2013-10-28 6:01 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, stephen, davem, Zhi Yong Wu
In-Reply-To: <1382940110-10737-1-git-send-email-zwu.kernel@gmail.com>
From: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
Signed-off-by: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
---
net/core/datagram.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/datagram.c b/net/core/datagram.c
index af814e7..a16ed7b 100644
--- a/net/core/datagram.c
+++ b/net/core/datagram.c
@@ -577,7 +577,7 @@ EXPORT_SYMBOL(skb_copy_datagram_from_iovec);
/**
* zerocopy_sg_from_iovec - Build a zerocopy datagram from an iovec
* @skb: buffer to copy
- * @from: io vector to copy to
+ * @from: io vector to copy from
* @offset: offset in the io vector to start copying from
* @count: amount of vectors to copy to buffer from
*
--
1.7.11.7
^ 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