Messages in this thread | | | From | Shinas Rasheed <> | Subject | RE: [EXT] Re: [PATCH net-next v2 3/4] octeon_ep: implement xmit_more in transmit | Date | Fri, 27 Oct 2023 11:25:16 +0000 |
| |
> -----Original Message----- > From: Jakub Kicinski <kuba@kernel.org> > Sent: Thursday, October 26, 2023 8:15 PM > To: Shinas Rasheed <srasheed@marvell.com> > Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Haseeb Gani > <hgani@marvell.com>; Vimlesh Kumar <vimleshk@marvell.com>; > egallen@redhat.com; mschmidt@redhat.com; pabeni@redhat.com; > horms@kernel.org; davem@davemloft.net; wizhao@redhat.com; > konguyen@redhat.com; Veerasenareddy Burru <vburru@marvell.com>; > Sathesh B Edara <sedara@marvell.com>; Eric Dumazet > <edumazet@google.com> > Subject: Re: [EXT] Re: [PATCH net-next v2 3/4] octeon_ep: implement > xmit_more in transmit > > On Thu, 26 Oct 2023 07:57:54 +0000 Shinas Rasheed wrote: > > >The recommended way of implementing 'driver flow control' > > is to stop the queue once next packet may not fit, and then use > > netif_xmit_stopped() when deciding whether we need to flush or we can > > trust xmit_more. see > > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__www.kernel.org_doc_html_next_networking_driver.html-23transmit- > 2Dpath-2Dguidelines&d=DwICAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=1OxLD4y- > oxrlgQ1rjXgWtmLz1pnaDjD96sDq- > cKUwK4&m=FyJHTb5Z2u9DTFSYPU38S5kPcP5KvwGWzY- > DPcqOl1gdnm7ToZhTFpyvhLMqh1hd&s=dBMmwfWKAi0UH3nrz7j9kYnAodDj > uN3LZ5tC2aL_Prs&e= > > > > >> In the skeleton code above, as I understand each tx desc holds a skb frag > and hence there can be possibility of receiving a full-sized skb, stopping the > queue but on receiving another normal skb we should observe our queue to > be stopped. This doesn't arise in our case as even if the skb is full-sized, it will > only use a single tx descriptor so we can be sure if queue has been stopped, > the write index will only be updated once posted (and read) tx descriptors > are processed in napi context and queues awoken. > > > > Please correct me if I'm wrong anywhere (sorry if so) to further my > understanding, and again thanks for your time! > > Could you please do some training on how to use normal / mailing list > style email at Marvell? Multiple people from Marvell can't quote > replies correctly, it makes it hard to have a conversation and help > y'all. Hi Jacub, apologizing for format errors on my part, will try to rectify in coming mails. Sorry again.
> -----Original Message----- > From: Eric Dumazet <edumazet@google.com> > Sent: Thursday, October 26, 2023 1:59 PM > To: Shinas Rasheed <srasheed@marvell.com> > Cc: Jakub Kicinski <kuba@kernel.org>; netdev@vger.kernel.org; linux- > kernel@vger.kernel.org; Haseeb Gani <hgani@marvell.com>; Vimlesh Kumar > <vimleshk@marvell.com>; egallen@redhat.com; mschmidt@redhat.com; > pabeni@redhat.com; horms@kernel.org; davem@davemloft.net; > wizhao@redhat.com; konguyen@redhat.com; Veerasenareddy Burru > <vburru@marvell.com>; Sathesh B Edara <sedara@marvell.com> > Subject: Re: [EXT] Re: [PATCH net-next v2 3/4] octeon_ep: implement > xmit_more in transmit > > Fact that octep_start_xmit() can return NETDEV_TX_BUSY is very suspicious. > > I do not think a driver can implement xmit_more and keep > NETDEV_TX_BUSY at the same time. > > Please make sure to remove NETDEV_TX_BUSY first, by stopping the queue > earlier.
Hi Eric, I think I understand your point and shall submit an updated patch. Thanks your time!
| |