All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Bhaskar Upadhaya <bupadhaya@marvell.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	Ariel Elior <aelior@marvell.com>,
	Igor Russkikh <irusskikh@marvell.com>,
	"davem@davemloft.net" <davem@davemloft.net>
Subject: Re: [EXT] Re: [PATCH net 1/2] qede: fix to disable start_xmit functionality during self adapter test
Date: Wed, 17 Mar 2021 11:40:59 -0700	[thread overview]
Message-ID: <20210317114059.28aa2aea@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> (raw)
In-Reply-To: <DM5PR18MB21529A16BF342B1DBC344403AB6A9@DM5PR18MB2152.namprd18.prod.outlook.com>

On Wed, 17 Mar 2021 06:33:37 +0000 Bhaskar Upadhaya wrote:
> > But an interrupt can come in after and enable Tx again.
> > I think you should keep the qede_netif_stop() here instead of moving it
> > down, no?  
> 
> Hi Jakub,
> Normal Traffic flow is enabled by qede_netif_start(edev) and which is placed at the end of this qede_selftest_run_loopback()
> qede_netif_stop(edev) is called prior to the call to qede_netif_start(edev), so unless qede_netif_start(edev)  is called Normal traffic flow will not
> be operational. 

I'm not talking about submitting more traffic.

Consider the following order of events

normal traffic		test

xmit()
			netif_tx_disable()
IRQ
NAPI
netif_tx_wake_queue()

     <--- traffic running again --->

			qede_netif_stop()

  reply	other threads:[~2021-03-17 18:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-16 18:34 [PATCH net 0/2] qede: fix ethernet self adapter and skb failure issue Bhaskar Upadhaya
2021-03-16 18:34 ` [PATCH net 1/2] qede: fix to disable start_xmit functionality during self adapter test Bhaskar Upadhaya
2021-03-16 21:59   ` Jakub Kicinski
2021-03-17  6:33     ` [EXT] " Bhaskar Upadhaya
2021-03-17 18:40       ` Jakub Kicinski [this message]
2021-03-16 18:34 ` [PATCH net 2/2] qede: fix memory allocation failures under heavy load Bhaskar Upadhaya

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210317114059.28aa2aea@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com \
    --to=kuba@kernel.org \
    --cc=aelior@marvell.com \
    --cc=bupadhaya@marvell.com \
    --cc=davem@davemloft.net \
    --cc=irusskikh@marvell.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.