* Re: [PATCH net-next 2/2] net: exit busy loop when another process is runnable
From: Jason Wang @ 2014-09-02 7:37 UTC (permalink / raw)
To: Eliezer Tamir, Ingo Molnar
Cc: Mike Galbraith, davem, netdev, linux-kernel, mst, Peter Zijlstra,
Ingo Molnar
In-Reply-To: <54056076.2030603@linux.intel.com>
On 09/02/2014 02:15 PM, Eliezer Tamir wrote:
> On 02/09/2014 06:29, Jason Wang wrote:
>> On 09/01/2014 02:39 PM, Eliezer Tamir wrote:
>>> On 29/08/2014 06:08, Jason Wang wrote:
>>>>> Yes, but rx busy polling only works in process context and does not
>>>>> disable bh, so it may be not an issue.
>>> sk_busy_loop() uses rcu_read_lock_bh(), so it does run with bh disabled.
>> True, so we need probably also exit the loop when there are pending bhs.
> I'm not so sure, in the typical busy poll scenario, the incoming
> traffic is the most time-critical thing in the system.
> It's so important that you are willing to trade lots of CPU power
> for better latency. The user has decided that he wants to dedicate
> this CPU mostly for that.
But user should increase the process priority or cgroup in this case.
> This is not something that plays nice with
> other apps, but this is what the user wants.
So the busy polling looks have a higher priority somehow than other
processes.
> So, you definitely don't want to starve any bh, and you should
> regularly re-enable bh's, but you also don't want to stop everything
> at any time a bh is scheduled.
If I get your meaning, you may want call to rcu_read_lock_bh() and get
socket napi id inside the do{} loop? This seems can prevent bhs from
being starved and can also handle the case that the packets were from
different NAPIs.
>
> You also want network processing on the queues that are busy polled
> to come through busy polling and not through NAPI, which is run in bh
> context.
>
> -Eliezer
> --
> 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 5/9] net: Have xmit_list() signal more==true when appropriate.
From: Jesper Dangaard Brouer @ 2014-09-02 7:25 UTC (permalink / raw)
To: David Miller; +Cc: brouer, netdev
In-Reply-To: <20140901.152459.592105486574617399.davem@davemloft.net>
On Mon, 01 Sep 2014 15:24:59 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
> diff --git a/net/core/dev.c b/net/core/dev.c
> index f0ed5a6..6d82194 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -2600,7 +2600,7 @@ netdev_features_t netif_skb_features(struct sk_buff *skb)
> EXPORT_SYMBOL(netif_skb_features);
>
> static int xmit_one(struct sk_buff *skb, struct net_device *dev,
> - struct netdev_queue *txq)
> + struct netdev_queue *txq, bool more)
> {
> unsigned int len;
> int rc;
> @@ -2610,7 +2610,7 @@ static int xmit_one(struct sk_buff *skb, struct net_device *dev,
>
> len = skb->len;
> trace_net_dev_start_xmit(skb, dev);
> - rc = netdev_start_xmit(skb, dev, txq, false);
> + rc = netdev_start_xmit(skb, dev, txq, more);
>
> trace_net_dev_xmit(skb, rc, dev, len);
>
> return rc;
> @@ -2626,7 +2626,7 @@ static struct sk_buff *xmit_list(struct sk_buff *first, struct net_device *dev,
> struct sk_buff *next = skb->next;
>
> skb->next = NULL;
> - rc = xmit_one(skb, dev, txq);
> + rc = xmit_one(skb, dev, txq, next != NULL);
Guess, the caller constructing the skb list to xmit_list() must make
sure all SKBs have the same TXQ.
> if (unlikely(!dev_xmit_complete(rc))) {
> skb->next = next;
> goto out;
In the exit case (!dev_xmit_complete(rc)) is it,
1. the responsibility of the driver to "flush" the tail, or
2. do we depend on qdisc or softirq to be reactivated soonish?
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* phpBB 3.1.0 new version
From: phpbbaid @ 2014-09-02 7:18 UTC (permalink / raw)
To: netdev
phpBB 3.1.0 new version is out .
Please update your forum to the latest version .
We provide paid support if you are interested, please, reply to this email
Thank you
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: exit busy loop when another process is runnable
From: Jason Wang @ 2014-09-02 7:19 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Michael S. Tsirkin, Mike Galbraith, davem, netdev, linux-kernel,
Ingo Molnar
In-Reply-To: <20140902061222.GE5806@worktop.ger.corp.intel.com>
On 09/02/2014 02:12 PM, Peter Zijlstra wrote:
> On Tue, Sep 02, 2014 at 11:38:40AM +0800, Jason Wang wrote:
>> > I see, how about just exporting a boolean helper like
>> > current_can_busy_loop() and take care all of the conditions (pending bhs
>> > and rcu callbacks, runnable processes) in scheduler code itself?
> How is that going to help the cases that are hurt by not spinning for a
> packet?
The patch does not help for this case. Spinning in the case only help
for a single process but hurt all others. Those other processes may not
use busy polling or even non network related. Spinning still may give
somewhat a high priority to the process who use busy polling or reading
which is unfair. And how much we can gain for only a single process by
spinning still when several other tasks could be done is still
questionable. It's quite possible that we could only get one or zero
packet after wasting lots of the cpu cycles when there are thousands or
more sockets.
^ permalink raw reply
* spam anyone?
From: Larry Xiao @ 2014-09-02 7:13 UTC (permalink / raw)
To: netdev; +Cc: xiaodi
In-Reply-To: <E1XOhPe-0007IU-5m@www17.pipni.cz>
Hi all,
I didn't see anyone complain about spam before.
So I don't know if it's only me receiving many spams like this one.
(I don't know if this email will go through .. )
Thanks!
Larry
On 9/2/14 2:17 PM, laurencesweio@bigpond.net.au wrote:
> Attn ,
>
> My name is Laurence Palmer, a banker at STB SA. I have a beneficial business propsal worth $15 Million for you. You are not going to spend any of your personal savings on this business transaction.
>
> I shall cover all expenses which might be necessary for this transaction to go through. I just need a honest individual as a partner. I will give 40% of the proceeds to you.
>
> Respond by email: palmerlaurence6@gmail.com
>
> Mr. Laurence Palmer
>
>
> --
> 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 1/9] net: Do txq_trans_update() in netdev_start_xmit()
From: Jesper Dangaard Brouer @ 2014-09-02 6:54 UTC (permalink / raw)
To: David Miller; +Cc: brouer, netdev
In-Reply-To: <20140901.152438.1000592701792724604.davem@davemloft.net>
On Mon, 01 Sep 2014 15:24:38 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
> That way we don't have to audit every call site to make sure it is
> doing this properly.
>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
> drivers/net/wan/dlci.c | 6 ++++--
Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
Nicely done, even caught that wan/dlci.c were not calling txq_trans_update(txq).
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: exit busy loop when another process is runnable
From: Jason Wang @ 2014-09-02 6:31 UTC (permalink / raw)
To: Eliezer Tamir, Eric Dumazet
Cc: Ingo Molnar, Mike Galbraith, davem, netdev, linux-kernel, mst,
Peter Zijlstra, Ingo Molnar jacob.e.keller@intel.com
In-Reply-To: <54055D9F.7000108@linux.intel.com>
On 09/02/2014 02:03 PM, Eliezer Tamir wrote:
> On 02/09/2014 06:35, Jason Wang wrote:
>> On 09/01/2014 02:55 PM, Eliezer Tamir wrote:
>>> On 26/08/2014 10:16, Jason Wang wrote:
>>>> On 08/25/2014 09:16 PM, Eliezer Tamir wrote:
>>> Think about the case where two processes are busy polling on the
>>> same CPU and the same device queue. Since busy polling processes
>>> incoming packets on the queue from any process, this scenario works
>>> well currently,
>> I see, but looks like we can simply do this by exiting the busy loop
>> when ndo_busy_poll() finds something but not for current socket?
> I don't think there is a need for that.
>
> When ndo_busy_poll() finds something it feeds it to the stack, which
> will process the packet, just as if it came from NAPI polling.
> So, if this is data that someone is blocked waiting on, the stack will
> wake them up, and then you presumably can decide which app should get
> the cpu.
Yes, but current code can not do this. In most of the cases, the new
woke up process have no chance to run if another process is busy loop in
the same cpu.
>
> Note, that there is no easy way to know, when looking at the
> incoming traffic, whether it is important, or even if you are seeing
> a full message. (Maybe you only have 9 packets out of 10?)
> The only place this knowledge might exist is in the layers of the
> stack closer to the user.
>
>>> and will not work at all when polling yields to other
>>> processes that are of the same priority that are running on the same
>>> CPU.
>>> Maybe the networking subsystem should maintain a list of device
>>> queues that need busypolling and have a thread that would poll
>>> all of them when there's nothing better to do.
>> Not sure whether this method will scale considering thousands of sockets
>> and processes.
> There may be millions of sockets, but in most cases only a handful of
> device queues per CPU to busy poll on. I have tested the epoll rfc
> code with hundreds of thousands of sockets and one or two device
> queues and is scales pretty well.
>
> The part I don't like in that code is the cumbersome mechanism I used
> to track the socket -> queue relationship. I think that if I had more
> time to work on it, I would instead look into extending the epoll
> interface so that libevent can tell the kernel what it wants, instead
> of having the busypoll code try and learn it.
I'd like to have a look at this rfc. Could you please give me a pointer?
I've done a quick search on kernel mailing list but didn't find it.
Thanks
>
> Cheers,
> Eliezer
^ permalink raw reply
* [PATCH net] qeth: don't query for info if hardware not ready.
From: Frank Blaschka @ 2014-09-02 6:20 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-s390
From: Eugene Crosser <Eugene.Crosser@ru.ibm.com>
When qeth device is queried for ethtool data, hardware operation
is performed to extract the necessary information from the card.
If the card is not online at the moment (e.g. it is undergoing
recovery), this operation produces undesired effects like
temporarily freezing the system. This patch prevents execution
of the hardware query operation when the card is not online.
In such case, ioctl() operation returns error with errno ENODEV.
Reviewed-by: Ursula Braun <ursula.braun@de.ibm.com>
Signed-off-by: Eugene Crosser <Eugene.Crosser@ru.ibm.com>
Signed-off-by: Frank Blaschka <blaschka@linux.vnet.ibm.com>
---
drivers/s390/net/qeth_core.h | 1 +
drivers/s390/net/qeth_core_main.c | 16 +++++++++++++++-
drivers/s390/net/qeth_l2_sys.c | 7 +------
3 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/s390/net/qeth_core.h b/drivers/s390/net/qeth_core.h
index 97ef37b..e7646ce 100644
--- a/drivers/s390/net/qeth_core.h
+++ b/drivers/s390/net/qeth_core.h
@@ -889,6 +889,7 @@ extern const struct attribute_group *qeth_generic_attr_groups[];
extern const struct attribute_group *qeth_osn_attr_groups[];
extern struct workqueue_struct *qeth_wq;
+int qeth_card_hw_is_reachable(struct qeth_card *);
const char *qeth_get_cardname_short(struct qeth_card *);
int qeth_realloc_buffer_pool(struct qeth_card *, int);
int qeth_core_load_discipline(struct qeth_card *, enum qeth_discipline_id);
diff --git a/drivers/s390/net/qeth_core_main.c b/drivers/s390/net/qeth_core_main.c
index c0d6ba8..fd22c81 100644
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -73,6 +73,13 @@ static int qeth_init_qdio_out_buf(struct qeth_qdio_out_q *, int);
struct workqueue_struct *qeth_wq;
EXPORT_SYMBOL_GPL(qeth_wq);
+int qeth_card_hw_is_reachable(struct qeth_card *card)
+{
+ return (card->state == CARD_STATE_SOFTSETUP) ||
+ (card->state == CARD_STATE_UP);
+}
+EXPORT_SYMBOL_GPL(qeth_card_hw_is_reachable);
+
static void qeth_close_dev_handler(struct work_struct *work)
{
struct qeth_card *card;
@@ -5790,6 +5797,7 @@ int qeth_core_ethtool_get_settings(struct net_device *netdev,
struct qeth_card *card = netdev->ml_priv;
enum qeth_link_types link_type;
struct carrier_info carrier_info;
+ int rc;
u32 speed;
if ((card->info.type == QETH_CARD_TYPE_IQD) || (card->info.guestlan))
@@ -5832,8 +5840,14 @@ int qeth_core_ethtool_get_settings(struct net_device *netdev,
/* Check if we can obtain more accurate information. */
/* If QUERY_CARD_INFO command is not supported or fails, */
/* just return the heuristics that was filled above. */
- if (qeth_query_card_info(card, &carrier_info) != 0)
+ if (!qeth_card_hw_is_reachable(card))
+ return -ENODEV;
+ rc = qeth_query_card_info(card, &carrier_info);
+ if (rc == -EOPNOTSUPP) /* for old hardware, return heuristic */
return 0;
+ if (rc) /* report error from the hardware operation */
+ return rc;
+ /* on success, fill in the information got from the hardware */
netdev_dbg(netdev,
"card info: card_type=0x%02x, port_mode=0x%04x, port_speed=0x%08x\n",
diff --git a/drivers/s390/net/qeth_l2_sys.c b/drivers/s390/net/qeth_l2_sys.c
index ae1bc04..59e3aa5 100644
--- a/drivers/s390/net/qeth_l2_sys.c
+++ b/drivers/s390/net/qeth_l2_sys.c
@@ -5,17 +5,12 @@
#include <linux/slab.h>
#include <asm/ebcdic.h>
+#include "qeth_core.h"
#include "qeth_l2.h"
#define QETH_DEVICE_ATTR(_id, _name, _mode, _show, _store) \
struct device_attribute dev_attr_##_id = __ATTR(_name, _mode, _show, _store)
-static int qeth_card_hw_is_reachable(struct qeth_card *card)
-{
- return (card->state == CARD_STATE_SOFTSETUP) ||
- (card->state == CARD_STATE_UP);
-}
-
static ssize_t qeth_bridge_port_role_state_show(struct device *dev,
struct device_attribute *attr, char *buf,
int show_state)
^ permalink raw reply related
* Please respond/-1/
From: laurencesweio @ 2014-09-02 6:17 UTC (permalink / raw)
To: netdev
Attn ,
My name is Laurence Palmer, a banker at STB SA. I have a beneficial business propsal worth $15 Million for you. You are not going to spend any of your personal savings on this business transaction.
I shall cover all expenses which might be necessary for this transaction to go through. I just need a honest individual as a partner. I will give 40% of the proceeds to you.
Respond by email: palmerlaurence6@gmail.com
Mr. Laurence Palmer
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: exit busy loop when another process is runnable
From: Eliezer Tamir @ 2014-09-02 6:15 UTC (permalink / raw)
To: Jason Wang, Ingo Molnar
Cc: Mike Galbraith, davem, netdev, linux-kernel, mst, Peter Zijlstra,
Ingo Molnar
In-Reply-To: <54053998.4040604@redhat.com>
On 02/09/2014 06:29, Jason Wang wrote:
> On 09/01/2014 02:39 PM, Eliezer Tamir wrote:
>> On 29/08/2014 06:08, Jason Wang wrote:
>>>> Yes, but rx busy polling only works in process context and does not
>>>> disable bh, so it may be not an issue.
>> sk_busy_loop() uses rcu_read_lock_bh(), so it does run with bh disabled.
>
> True, so we need probably also exit the loop when there are pending bhs.
I'm not so sure, in the typical busy poll scenario, the incoming
traffic is the most time-critical thing in the system.
It's so important that you are willing to trade lots of CPU power
for better latency. The user has decided that he wants to dedicate
this CPU mostly for that. This is not something that plays nice with
other apps, but this is what the user wants.
So, you definitely don't want to starve any bh, and you should
regularly re-enable bh's, but you also don't want to stop everything
at any time a bh is scheduled.
You also want network processing on the queues that are busy polled
to come through busy polling and not through NAPI, which is run in bh
context.
-Eliezer
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: exit busy loop when another process is runnable
From: Peter Zijlstra @ 2014-09-02 6:12 UTC (permalink / raw)
To: Jason Wang
Cc: Michael S. Tsirkin, Mike Galbraith, davem, netdev, linux-kernel,
Ingo Molnar
In-Reply-To: <54053BC0.6060700@redhat.com>
On Tue, Sep 02, 2014 at 11:38:40AM +0800, Jason Wang wrote:
> I see, how about just exporting a boolean helper like
> current_can_busy_loop() and take care all of the conditions (pending bhs
> and rcu callbacks, runnable processes) in scheduler code itself?
How is that going to help the cases that are hurt by not spinning for a
packet?
^ permalink raw reply
* Re: [PATCH (net.git)] stmmac: fix and review whole driver locking
From: Giuseppe CAVALLARO @ 2014-09-02 6:05 UTC (permalink / raw)
To: davem, bigeasy, khoroshilov; +Cc: netdev
In-Reply-To: <1409637603-17347-1-git-send-email-peppe.cavallaro@st.com>
Hello
as discussed in the mailing list the driver had some known problems
on locking so I tried to collect all the fixes in this small patch
trying to finalize and fix them.
Let me know if you see some other issues and welcome advice in case of
I missed something else.
On my side, no issue when proving locks so no warning anymore and
no issues while testing the driver.
br
peppe
On 9/2/2014 8:00 AM, Giuseppe Cavallaro wrote:
> This patch is to fix/review the whole lock protection inside the driver.
>
> Proving locks several warning were detected.
>
> The patch reviews the tx lock removing it because the driver
> claims the resource in NAPI context and, as designed, can run
> w/o any own extra lock (so just netif_tx_lock).
> This shows an impact on performances too.
>
> Then the patch removes useless lock in set_filter and resume
> functions.
> It finally fixes the concurrency in eee initialization.
> Prior this patch, the stmmac_eee_init could be called
> in several places as shown below:
>
> stmmac_open stmmac_resume PHY Layer
> | | |
> |___stmmac_hw_setup ___| stmmac_adjust_link
> | |
> |_________________ stmmac_eee_init ___________|
>
> The patch tries to solve problem just removing the stmmac_eee_init
> call inside the stmmac_hw_setup that is unnecessary. It is sufficient
> to call it in the stmmac_adjust_link to always guarantee that the EEE
> is configured. In fact, after the new link is adjusted then the driver
> can check the EEE capability and then eventually enable it at MAC level.
>
> Always on the adjust link, this patch removes the disable irq when
> not necessary because it should be just called by phy_change.
>
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/stmmac.h | 1 -
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 28 +++++---------------
> 2 files changed, 7 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
> index 58097c0..e8ebab2 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
> @@ -54,7 +54,6 @@ struct stmmac_priv {
> dma_addr_t dma_tx_phy;
> int tx_coalesce;
> int hwts_tx_en;
> - spinlock_t tx_lock;
> bool tx_path_in_lpi_mode;
> struct timer_list txtimer;
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 3d3db16..92db429 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -685,14 +685,13 @@ static void stmmac_adjust_link(struct net_device *dev)
> {
> struct stmmac_priv *priv = netdev_priv(dev);
> struct phy_device *phydev = priv->phydev;
> - unsigned long flags;
> int new_state = 0;
> unsigned int fc = priv->flow_ctrl, pause_time = priv->pause;
>
> if (phydev == NULL)
> return;
>
> - spin_lock_irqsave(&priv->lock, flags);
> + spin_lock(&priv->lock);
>
> if (phydev->link) {
> u32 ctrl = readl(priv->ioaddr + MAC_CTRL_REG);
> @@ -760,12 +759,12 @@ static void stmmac_adjust_link(struct net_device *dev)
> if (new_state && netif_msg_link(priv))
> phy_print_status(phydev);
>
> + spin_unlock(&priv->lock);
> +
> /* At this stage, it could be needed to setup the EEE or adjust some
> * MAC related HW registers.
> */
> priv->eee_enabled = stmmac_eee_init(priv);
> -
> - spin_unlock_irqrestore(&priv->lock, flags);
> }
>
> /**
> @@ -1280,8 +1279,6 @@ static void stmmac_tx_clean(struct stmmac_priv *priv)
> {
> unsigned int txsize = priv->dma_tx_size;
>
> - spin_lock(&priv->tx_lock);
> -
> priv->xstats.tx_clean++;
>
> while (priv->dirty_tx != priv->cur_tx) {
> @@ -1359,7 +1356,6 @@ static void stmmac_tx_clean(struct stmmac_priv *priv)
> stmmac_enable_eee_mode(priv);
> mod_timer(&priv->eee_ctrl_timer, STMMAC_LPI_T(eee_timer));
> }
> - spin_unlock(&priv->tx_lock);
> }
>
> static inline void stmmac_enable_dma_irq(struct stmmac_priv *priv)
> @@ -1704,8 +1700,6 @@ static int stmmac_hw_setup(struct net_device *dev)
> }
> priv->tx_lpi_timer = STMMAC_DEFAULT_TWT_LS;
>
> - priv->eee_enabled = stmmac_eee_init(priv);
> -
> stmmac_init_tx_coalesce(priv);
>
> if ((priv->use_riwt) && (priv->hw->dma->rx_watchdog)) {
> @@ -1881,6 +1875,8 @@ static int stmmac_release(struct net_device *dev)
> * Description : this is the tx entry point of the driver.
> * It programs the chain or the ring and supports oversized frames
> * and SG feature.
> + * Transmit resources are claimed in napi context and currency is solved with
> + * netif_tx_lock so no extra locks are needed.
> */
> static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
> {
> @@ -1902,8 +1898,6 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
> return NETDEV_TX_BUSY;
> }
>
> - spin_lock(&priv->tx_lock);
> -
> if (priv->tx_path_in_lpi_mode)
> stmmac_disable_eee_mode(priv);
>
> @@ -2020,7 +2014,6 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
>
> priv->hw->dma->enable_dma_transmission(priv->ioaddr);
>
> - spin_unlock(&priv->tx_lock);
> return NETDEV_TX_OK;
>
> dma_map_err:
> @@ -2280,9 +2273,7 @@ static void stmmac_set_rx_mode(struct net_device *dev)
> {
> struct stmmac_priv *priv = netdev_priv(dev);
>
> - spin_lock(&priv->lock);
> priv->hw->mac->set_filter(priv->hw, dev);
> - spin_unlock(&priv->lock);
> }
>
> /**
> @@ -2816,7 +2807,6 @@ struct stmmac_priv *stmmac_dvr_probe(struct device *device,
> netif_napi_add(ndev, &priv->napi, stmmac_poll, 64);
>
> spin_lock_init(&priv->lock);
> - spin_lock_init(&priv->tx_lock);
>
> ret = register_netdev(ndev);
> if (ret) {
> @@ -2916,6 +2906,8 @@ int stmmac_suspend(struct net_device *ndev)
>
> stmmac_clear_descriptors(priv);
>
> + spin_unlock_irqrestore(&priv->lock, flags);
> +
> /* Enable Power down mode by programming the PMT regs */
> if (device_may_wakeup(priv->device)) {
> priv->hw->mac->pmt(priv->hw, priv->wolopts);
> @@ -2926,7 +2918,6 @@ int stmmac_suspend(struct net_device *ndev)
> /* Disable clock in case of PWM is off */
> clk_disable_unprepare(priv->stmmac_clk);
> }
> - spin_unlock_irqrestore(&priv->lock, flags);
>
> priv->oldlink = 0;
> priv->speed = 0;
> @@ -2937,13 +2928,10 @@ int stmmac_suspend(struct net_device *ndev)
> int stmmac_resume(struct net_device *ndev)
> {
> struct stmmac_priv *priv = netdev_priv(ndev);
> - unsigned long flags;
>
> if (!netif_running(ndev))
> return 0;
>
> - spin_lock_irqsave(&priv->lock, flags);
> -
> /* Power Down bit, into the PM register, is cleared
> * automatically as soon as a magic packet or a Wake-up frame
> * is received. Anyway, it's better to manually clear
> @@ -2970,8 +2958,6 @@ int stmmac_resume(struct net_device *ndev)
>
> netif_start_queue(ndev);
>
> - spin_unlock_irqrestore(&priv->lock, flags);
> -
> if (priv->phydev)
> phy_start(priv->phydev);
>
>
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: exit busy loop when another process is runnable
From: Eliezer Tamir @ 2014-09-02 6:03 UTC (permalink / raw)
To: Jason Wang, Eric Dumazet
Cc: Ingo Molnar, Mike Galbraith, davem, netdev, linux-kernel, mst,
Peter Zijlstra, Ingo Molnar jacob.e.keller@intel.com
In-Reply-To: <54053AF8.6070907@redhat.com>
On 02/09/2014 06:35, Jason Wang wrote:
> On 09/01/2014 02:55 PM, Eliezer Tamir wrote:
>> On 26/08/2014 10:16, Jason Wang wrote:
>>> On 08/25/2014 09:16 PM, Eliezer Tamir wrote:
>> Think about the case where two processes are busy polling on the
>> same CPU and the same device queue. Since busy polling processes
>> incoming packets on the queue from any process, this scenario works
>> well currently,
>
> I see, but looks like we can simply do this by exiting the busy loop
> when ndo_busy_poll() finds something but not for current socket?
I don't think there is a need for that.
When ndo_busy_poll() finds something it feeds it to the stack, which
will process the packet, just as if it came from NAPI polling.
So, if this is data that someone is blocked waiting on, the stack will
wake them up, and then you presumably can decide which app should get
the cpu.
Note, that there is no easy way to know, when looking at the
incoming traffic, whether it is important, or even if you are seeing
a full message. (Maybe you only have 9 packets out of 10?)
The only place this knowledge might exist is in the layers of the
stack closer to the user.
>> and will not work at all when polling yields to other
>> processes that are of the same priority that are running on the same
>> CPU.
>
>>
>> Maybe the networking subsystem should maintain a list of device
>> queues that need busypolling and have a thread that would poll
>> all of them when there's nothing better to do.
>
> Not sure whether this method will scale considering thousands of sockets
> and processes.
There may be millions of sockets, but in most cases only a handful of
device queues per CPU to busy poll on. I have tested the epoll rfc
code with hundreds of thousands of sockets and one or two device
queues and is scales pretty well.
The part I don't like in that code is the cumbersome mechanism I used
to track the socket -> queue relationship. I think that if I had more
time to work on it, I would instead look into extending the epoll
interface so that libevent can tell the kernel what it wants, instead
of having the busypoll code try and learn it.
Cheers,
Eliezer
^ permalink raw reply
* Re: [PATCHv2 net 0/6] Trivial fixes for cxgb4
From: David Miller @ 2014-09-02 6:01 UTC (permalink / raw)
To: hariprasad; +Cc: netdev, leedom, nirranjan, kumaras, anish
In-Reply-To: <1409581500-11264-1-git-send-email-hariprasad@chelsio.com>
From: Hariprasad Shenai <hariprasad@chelsio.com>
Date: Mon, 1 Sep 2014 19:54:54 +0530
> This patch series adds support to fix T5 adapter accessing T4 adapter registers,
> issue mbox command on correct mbox for physical function, avoid dumping write
> only registers, use correct length for adapter part number and support to detect
> and display firmware reported errors.
>
> The patches series is created against 'net' tree.
> And includes patches on cxgb4 driver.
>
> We have included all the maintainers of respective drivers. Kindly review the
> change and let us know in case of any review comments.
>
> Thanks
>
> V2:
> Added description for each patch as per David Miller's comment
Series applied, thanks.
^ permalink raw reply
* [PATCH (net.git)] stmmac: fix and review whole driver locking
From: Giuseppe Cavallaro @ 2014-09-02 6:00 UTC (permalink / raw)
To: netdev; +Cc: davem, bigeasy, khoroshilov, Giuseppe Cavallaro
This patch is to fix/review the whole lock protection inside the driver.
Proving locks several warning were detected.
The patch reviews the tx lock removing it because the driver
claims the resource in NAPI context and, as designed, can run
w/o any own extra lock (so just netif_tx_lock).
This shows an impact on performances too.
Then the patch removes useless lock in set_filter and resume
functions.
It finally fixes the concurrency in eee initialization.
Prior this patch, the stmmac_eee_init could be called
in several places as shown below:
stmmac_open stmmac_resume PHY Layer
| | |
|___stmmac_hw_setup ___| stmmac_adjust_link
| |
|_________________ stmmac_eee_init ___________|
The patch tries to solve problem just removing the stmmac_eee_init
call inside the stmmac_hw_setup that is unnecessary. It is sufficient
to call it in the stmmac_adjust_link to always guarantee that the EEE
is configured. In fact, after the new link is adjusted then the driver
can check the EEE capability and then eventually enable it at MAC level.
Always on the adjust link, this patch removes the disable irq when
not necessary because it should be just called by phy_change.
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 1 -
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 28 +++++---------------
2 files changed, 7 insertions(+), 22 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index 58097c0..e8ebab2 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -54,7 +54,6 @@ struct stmmac_priv {
dma_addr_t dma_tx_phy;
int tx_coalesce;
int hwts_tx_en;
- spinlock_t tx_lock;
bool tx_path_in_lpi_mode;
struct timer_list txtimer;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 3d3db16..92db429 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -685,14 +685,13 @@ static void stmmac_adjust_link(struct net_device *dev)
{
struct stmmac_priv *priv = netdev_priv(dev);
struct phy_device *phydev = priv->phydev;
- unsigned long flags;
int new_state = 0;
unsigned int fc = priv->flow_ctrl, pause_time = priv->pause;
if (phydev == NULL)
return;
- spin_lock_irqsave(&priv->lock, flags);
+ spin_lock(&priv->lock);
if (phydev->link) {
u32 ctrl = readl(priv->ioaddr + MAC_CTRL_REG);
@@ -760,12 +759,12 @@ static void stmmac_adjust_link(struct net_device *dev)
if (new_state && netif_msg_link(priv))
phy_print_status(phydev);
+ spin_unlock(&priv->lock);
+
/* At this stage, it could be needed to setup the EEE or adjust some
* MAC related HW registers.
*/
priv->eee_enabled = stmmac_eee_init(priv);
-
- spin_unlock_irqrestore(&priv->lock, flags);
}
/**
@@ -1280,8 +1279,6 @@ static void stmmac_tx_clean(struct stmmac_priv *priv)
{
unsigned int txsize = priv->dma_tx_size;
- spin_lock(&priv->tx_lock);
-
priv->xstats.tx_clean++;
while (priv->dirty_tx != priv->cur_tx) {
@@ -1359,7 +1356,6 @@ static void stmmac_tx_clean(struct stmmac_priv *priv)
stmmac_enable_eee_mode(priv);
mod_timer(&priv->eee_ctrl_timer, STMMAC_LPI_T(eee_timer));
}
- spin_unlock(&priv->tx_lock);
}
static inline void stmmac_enable_dma_irq(struct stmmac_priv *priv)
@@ -1704,8 +1700,6 @@ static int stmmac_hw_setup(struct net_device *dev)
}
priv->tx_lpi_timer = STMMAC_DEFAULT_TWT_LS;
- priv->eee_enabled = stmmac_eee_init(priv);
-
stmmac_init_tx_coalesce(priv);
if ((priv->use_riwt) && (priv->hw->dma->rx_watchdog)) {
@@ -1881,6 +1875,8 @@ static int stmmac_release(struct net_device *dev)
* Description : this is the tx entry point of the driver.
* It programs the chain or the ring and supports oversized frames
* and SG feature.
+ * Transmit resources are claimed in napi context and currency is solved with
+ * netif_tx_lock so no extra locks are needed.
*/
static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
{
@@ -1902,8 +1898,6 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
return NETDEV_TX_BUSY;
}
- spin_lock(&priv->tx_lock);
-
if (priv->tx_path_in_lpi_mode)
stmmac_disable_eee_mode(priv);
@@ -2020,7 +2014,6 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
priv->hw->dma->enable_dma_transmission(priv->ioaddr);
- spin_unlock(&priv->tx_lock);
return NETDEV_TX_OK;
dma_map_err:
@@ -2280,9 +2273,7 @@ static void stmmac_set_rx_mode(struct net_device *dev)
{
struct stmmac_priv *priv = netdev_priv(dev);
- spin_lock(&priv->lock);
priv->hw->mac->set_filter(priv->hw, dev);
- spin_unlock(&priv->lock);
}
/**
@@ -2816,7 +2807,6 @@ struct stmmac_priv *stmmac_dvr_probe(struct device *device,
netif_napi_add(ndev, &priv->napi, stmmac_poll, 64);
spin_lock_init(&priv->lock);
- spin_lock_init(&priv->tx_lock);
ret = register_netdev(ndev);
if (ret) {
@@ -2916,6 +2906,8 @@ int stmmac_suspend(struct net_device *ndev)
stmmac_clear_descriptors(priv);
+ spin_unlock_irqrestore(&priv->lock, flags);
+
/* Enable Power down mode by programming the PMT regs */
if (device_may_wakeup(priv->device)) {
priv->hw->mac->pmt(priv->hw, priv->wolopts);
@@ -2926,7 +2918,6 @@ int stmmac_suspend(struct net_device *ndev)
/* Disable clock in case of PWM is off */
clk_disable_unprepare(priv->stmmac_clk);
}
- spin_unlock_irqrestore(&priv->lock, flags);
priv->oldlink = 0;
priv->speed = 0;
@@ -2937,13 +2928,10 @@ int stmmac_suspend(struct net_device *ndev)
int stmmac_resume(struct net_device *ndev)
{
struct stmmac_priv *priv = netdev_priv(ndev);
- unsigned long flags;
if (!netif_running(ndev))
return 0;
- spin_lock_irqsave(&priv->lock, flags);
-
/* Power Down bit, into the PM register, is cleared
* automatically as soon as a magic packet or a Wake-up frame
* is received. Anyway, it's better to manually clear
@@ -2970,8 +2958,6 @@ int stmmac_resume(struct net_device *ndev)
netif_start_queue(ndev);
- spin_unlock_irqrestore(&priv->lock, flags);
-
if (priv->phydev)
phy_start(priv->phydev);
--
1.7.4.4
^ permalink raw reply related
* Re: [PATCH net] bnx2x: Configure device endianity on driver load and reset endianity on removal.
From: David Miller @ 2014-09-02 5:56 UTC (permalink / raw)
To: Yuval.Mintz; +Cc: manish.chopra, netdev, Ariel.Elior
In-Reply-To: <B5657A6538887040AD3A81F1008BEC63B30338@avmb3.qlogic.org>
From: Yuval Mintz <Yuval.Mintz@qlogic.com>
Date: Tue, 2 Sep 2014 05:47:49 +0000
> It's true #2 can solve the issue on its own for new kernels, but
> given the various existing distros out there (that don't include the
> fix) the effort of supporting those by adding #1 seems to be very
> small.
Ok, fair enough.
^ permalink raw reply
* RE: [PATCH net] bnx2x: Configure device endianity on driver load and reset endianity on removal.
From: Yuval Mintz @ 2014-09-02 5:47 UTC (permalink / raw)
To: David Miller, Manish Chopra; +Cc: netdev, Ariel Elior
In-Reply-To: <20140901.145314.1237097170646182877.davem@davemloft.net>
>> This patch fixes this case from both ends:
>>> 1) Return endianity to original values on shutdown (in case little endian kernel
>>> boots after we shutdown).
>>> 2) Do not rely on HW reset values when loading driver in little endian kernel
>>> but configure them explicitly (in case previous kernel was big endian and did
>>> not reset the HW).
...
>> David, Please drop this patch as it might create issue for VFs.
>> I will send updated V2 patch with proper fix.
>I think part #2 is the only reasonable part of this patch, and that's
>what you'll have to backport to -stable kernels to sort this out
>properly.
>Adding "unconfiguration" hacks into a driver to deal with driver bugs
>is really not kosher, sorry.
Why call this a hack?
It's true #2 can solve the issue on its own for new kernels, but given the various existing distros out there (that don't include the fix) the effort of supporting those by adding #1 seems to be very small.
I wouldn't say it's not kosher; more like milchig.
But then again, this is your domain and in truth constellations needing this fix are quite odd. If you insist we'll throw #1 away.
^ permalink raw reply
* Re: [PATCH] netlink: Safer deletion of sk_bind_node
From: David Miller @ 2014-09-02 5:03 UTC (permalink / raw)
To: HarishJennyKN
Cc: dborkman, tgraf, ebiederm, darkjames-ws, rgb, eric.dumazet,
stephen, netdev, linux-kernel
In-Reply-To: <1409555309-5893-1-git-send-email-harish_kandiga@mentor.com>
From: Harish Jenny K N
Date: Mon, 1 Sep 2014 12:38:29 +0530
Firstly, you really need to fix your outgoing email so that your email
address appears in your From: header properly.
> From: Harish Jenny K N <harish_kandiga@mentor.com>
>
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> (netlink_release+0x0/0x2a0) from [<8034e78c>] (sock_release+0x28/0xa4)
> (sock_release+0x0/0xa4) from [<8034e830>] (sock_close+0x28/0x34)
> (sock_close+0x0/0x34) from [<800f3490>] (__fput+0xf0/0x1ec)
> (__fput+0x0/0x1ec) from [<800f3634>] (____fput+0x10/0x14)
> (____fput+0x0/0x14) from [<80040a64>] (task_work_run+0xb8/0xd8)
> (task_work_run+0x0/0xd8) from [<800113a0>] (do_work_pending+0xb0/0xc4)
> (do_work_pending+0x0/0xc4) from [<8000d960>] (work_pending+0xc/0x20)
> Call flow of the inline and static functions
> netlink_release
> -----netlink_remove
> ---------__sk_del_bind_node
> --------------__hlist_del
>
> Signed-off-by: Harish Jenny K N <harish_kandiga@mentor.com>
This doesn't tell us anything about how this situation can be
arrived at.
When subscriptions changes, we delete the node with the table lock
held if subscriptions goes to zero. We only try to delete the node
when subscriptions was zero.
^ permalink raw reply
* Re: [PATCH (net.git) 2/2] stmmac: only remove RXCSUM feature if no rx coe is available
From: David Miller @ 2014-09-02 4:52 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev
In-Reply-To: <1409555873-5478-2-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Date: Mon, 1 Sep 2014 09:17:53 +0200
> In case of the HW is not able to do the receive checksum offloading
> the only feature to remove is NETIF_F_RXCSUM.
>
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Applied.
^ permalink raw reply
* Re: [PATCH (net.git) 1/2] stmmac: fix the rx csum feature
From: David Miller @ 2014-09-02 4:52 UTC (permalink / raw)
To: peppe.cavallaro; +Cc: netdev
In-Reply-To: <1409555873-5478-1-git-send-email-peppe.cavallaro@st.com>
From: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Date: Mon, 1 Sep 2014 09:17:52 +0200
> For new GMACs it is possible to turn-on/off the COE.
> In the current driver, when disabled the Rx-checksum
> via ethtool, the tool reported that csum was disabled
> but the HW continued to set the IPC. Indeed this is
> because the fix_features allows this. So the patch
> fixes this problem by adding the set_features.
>
> Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] sock: deduplicate errqueue dequeue
From: David Miller @ 2014-09-02 4:49 UTC (permalink / raw)
To: willemb; +Cc: netdev
In-Reply-To: <1409535027-16963-1-git-send-email-willemb@google.com>
From: Willem de Bruijn <willemb@google.com>
Date: Sun, 31 Aug 2014 21:30:27 -0400
> sk->sk_error_queue is dequeued in four locations. All share the
> exact same logic. Deduplicate.
>
> Also collapse the two critical sections for dequeue (at the top of
> the recv handler) and signal (at the bottom).
>
> This moves signal generation for the next packet forward, which should
> be harmless.
>
> It also changes the behavior if the recv handler exits early with an
> error. Previously, a signal for follow-up packets on the errqueue
> would then not be scheduled. The new behavior, to always signal, is
> arguably a bug fix.
>
> For rxrpc, the change causes the same function to be called repeatedly
> for each queued packet (because the recv handler == sk_error_report).
> It is likely that all packets will fail for the same reason (e.g.,
> memory exhaustion).
>
> This code runs without sk_lock held, so it is not safe to trust that
> sk->sk_err is immutable inbetween releasing q->lock and the subsequent
> test. Introduce int err just to avoid this potential race.
>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net-timestamp: expand documentation
From: David Miller @ 2014-09-02 4:49 UTC (permalink / raw)
To: willemb; +Cc: netdev
In-Reply-To: <1409534867-32710-1-git-send-email-willemb@google.com>
From: Willem de Bruijn <willemb@google.com>
Date: Sun, 31 Aug 2014 21:27:47 -0400
> Expand Documentation/networking/timestamping.txt with new
> interfaces and bytestream timestamping. Also minor
> cleanup of the other text.
>
> Import txtimestamp.c test of the new features.
>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
Applied, thanks for the test case.
^ permalink raw reply
* Re: [PATCH net-next 0/6] net: Checksum offload changes - Part VI
From: David Miller @ 2014-09-02 4:42 UTC (permalink / raw)
To: therbert; +Cc: netdev
In-Reply-To: <1409523166-9215-1-git-send-email-therbert@google.com>
From: Tom Herbert <therbert@google.com>
Date: Sun, 31 Aug 2014 15:12:40 -0700
> I am working on overhauling RX checksum offload. Goals of this effort
> are:
>
> - Specify what exactly it means when driver returns CHECKSUM_UNNECESSARY
> - Preserve CHECKSUM_COMPLETE through encapsulation layers
> - Don't do skb_checksum more than once per packet
> - Unify GRO and non-GRO csum verification as much as possible
> - Unify the checksum functions (checksum_init)
> - Simplify code
>
> What is in this seventh patch set:
>
> - Add skb->csum. This allows a device or GRO to indicate that an
> invalid checksum was detected.
> - Checksum unncessary to checksum complete conversions.
>
> With these changes, I believe that the third goal of the overhaul is
> now mostly achieved. In the case of no encapsulation or one layer of
> encapsulation, there should only be at most one skb_checksum over
> each packet (between GRO and normal path). In the case of two layers
> of encapsulation, it is still possible with the right combination of
> non-zero and zero UDP checksums to have >1 skb_checksum. For instance:
> IP>GRE(with csum)>IP>UDP(zero csum)>VXLAN>IP>UDP(non-zero csum),
> would likely necessiate an skb_checksum in GRO and normal path.
> This doesn't seem like a common scenario at all so I'm inclined to
> not address this now, if multiple layers of encapsulation becomes
> popular we can reassess.
>
> Note that checksum conversion shows a nice improvement for RX VXLAN when
> outer UDP checksum is enabled (12.65% CPU compared to 20.94%). This
> is not only from the fact that we don't need checksum calculation on
> the host, but also allows GRO for VXLAN in this case. Checksum
> conversion does not help send side (which still needs to perform
> a checksum on host). For that we will implement remote checksum offload
> in a later patch
> (http://tools.ietf.org/html/draft-herbert-remotecsumoffload-00).
>
> Please review carefully and test if possible, mucking with basic
> checksum functions is always a little precarious :-)
Awesome work, I love watching infrastructure gradually fall into
place like this :-)
Series applied, thanks!
^ permalink raw reply
* [PATCH v2 net-next 11/12] be2net: define macro for_all_tx_queues_on_eq()
From: Sathya Perla @ 2014-09-02 4:26 UTC (permalink / raw)
To: netdev
In-Reply-To: <1409632017-15655-1-git-send-email-sathya.perla@emulex.com>
Replace the for() loop that traverses all the TX queues on an EQ
with the macro for_all_tx_queues_on_eq(). With this expalnatory
name, the one line comment is not required anymore.
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
---
drivers/net/ethernet/emulex/benet/be.h | 4 ++++
drivers/net/ethernet/emulex/benet/be_main.c | 6 +++---
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be.h b/drivers/net/ethernet/emulex/benet/be.h
index d952ca2..a9f239a 100644
--- a/drivers/net/ethernet/emulex/benet/be.h
+++ b/drivers/net/ethernet/emulex/benet/be.h
@@ -621,6 +621,10 @@ extern const struct ethtool_ops be_ethtool_ops;
for (i = eqo->idx, rxo = &adapter->rx_obj[i]; i < adapter->num_rx_qs;\
i += adapter->num_evt_qs, rxo += adapter->num_evt_qs)
+#define for_all_tx_queues_on_eq(adapter, eqo, txo, i) \
+ for (i = eqo->idx, txo = &adapter->tx_obj[i]; i < adapter->num_tx_qs;\
+ i += adapter->num_evt_qs, txo += adapter->num_evt_qs)
+
#define is_mcc_eqo(eqo) (eqo->idx == 0)
#define mcc_eqo(adapter) (&adapter->eq_obj[0])
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index 53727ad..f3235d1 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -2503,12 +2503,12 @@ int be_poll(struct napi_struct *napi, int budget)
struct be_adapter *adapter = eqo->adapter;
int max_work = 0, work, i, num_evts;
struct be_rx_obj *rxo;
+ struct be_tx_obj *txo;
num_evts = events_get(eqo);
- /* Process all TXQs serviced by this EQ */
- for (i = eqo->idx; i < adapter->num_tx_qs; i += adapter->num_evt_qs)
- be_process_tx(adapter, &adapter->tx_obj[i], i);
+ for_all_tx_queues_on_eq(adapter, eqo, txo, i)
+ be_process_tx(adapter, txo, i);
if (be_lock_napi(eqo)) {
/* This loop will iterate twice for EQ0 in which
--
1.7.1
^ permalink raw reply related
* [PATCH v2 net-next 12/12] be2net: query max_tx_qs for BE3 super-nic profile from FW
From: Sathya Perla @ 2014-09-02 4:26 UTC (permalink / raw)
To: netdev
In-Reply-To: <1409632017-15655-1-git-send-email-sathya.perla@emulex.com>
From: Suresh Reddy <Suresh.Reddy@emulex.com>
In the BE3 super-nic profile, the max_tx_qs value can vary for each function.
So the driver needs to query this value from FW instead of using the
pre-defined constant BE3_MAX_TX_QS.
Signed-off-by: Suresh Reddy <Suresh.Reddy@emulex.com>
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
---
drivers/net/ethernet/emulex/benet/be_main.c | 14 ++++++++++++--
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index f3235d1..9eaab4e 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -3324,10 +3324,20 @@ static void BEx_get_resources(struct be_adapter *adapter,
*/
if (BE2_chip(adapter) || use_sriov || (adapter->port_num > 1) ||
!be_physfn(adapter) || (be_is_mc(adapter) &&
- !(adapter->function_caps & BE_FUNCTION_CAPS_RSS)))
+ !(adapter->function_caps & BE_FUNCTION_CAPS_RSS))) {
res->max_tx_qs = 1;
- else
+ } else if (adapter->function_caps & BE_FUNCTION_CAPS_SUPER_NIC) {
+ struct be_resources super_nic_res = {0};
+
+ /* On a SuperNIC profile, the driver needs to use the
+ * GET_PROFILE_CONFIG cmd to query the per-function TXQ limits
+ */
+ be_cmd_get_profile_config(adapter, &super_nic_res, 0);
+ /* Some old versions of BE3 FW don't report max_tx_qs value */
+ res->max_tx_qs = super_nic_res.max_tx_qs ? : BE3_MAX_TX_QS;
+ } else {
res->max_tx_qs = BE3_MAX_TX_QS;
+ }
if ((adapter->function_caps & BE_FUNCTION_CAPS_RSS) &&
!use_sriov && be_physfn(adapter))
--
1.7.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