Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1544832
| From | Francois Romieu <romieu@fr.zoreil.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock |
| Date | 2016-12-20 01:10 +0100 |
| Message-ID | <sQgae-6pr-7@gated-at.bofh.it> (permalink) |
| References | (5 earlier) <sOLUR-2xu-7@gated-at.bofh.it> <sOMQW-38F-19@gated-at.bofh.it> <sPr7H-4aS-1@gated-at.bofh.it> <sPxmO-8sN-7@gated-at.bofh.it> <sQ33k-6mo-5@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Pavel Machek <pavel@ucw.cz> : [...] > Considering the memory barriers... is something like this neccessary > in the via-rhine ? Yes. > AFAICT... we need a barrier after making sure that descriptor is no > longer owned by DMA (to make sure we don't get stale data in rest of > descriptor)... and we need a barrier before giving the descriptor to > the dma, to make sure DMA engine sees the complete update....? I would not expect stale data while processing a single transmit descriptor as the transmit completion does not use the rest of the descriptor at all in the via-rhine driver. However I agree that transmit descriptors should be read by the cpu with adequate ordering so the dma_rmb() should stay. Same kind of narrative for dma_wmb rhine_rx (s/read/written/ and s/cpu/device/). > diff --git a/drivers/net/ethernet/via/via-rhine.c b/drivers/net/ethernet/via/via-rhine.c > index ba5c542..3806e72 100644 > --- a/drivers/net/ethernet/via/via-rhine.c > +++ b/drivers/net/ethernet/via/via-rhine.c [...] > @@ -2061,6 +2062,7 @@ static int rhine_rx(struct net_device *dev, int limit) > > if (desc_status & DescOwn) > break; > + dma_rmb(); > I agree with your explanation for this one (late vlan processing in a different word from the same descriptor). -- Ueimor
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock Pavel Machek <pavel@ucw.cz> - 2016-12-11 21:20 +0100
Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock Lino Sanfilippo <LinoSanfilippo@gmx.de> - 2016-12-15 20:30 +0100
Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock Pavel Machek <pavel@ucw.cz> - 2016-12-15 22:20 +0100
Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock Lino Sanfilippo <LinoSanfilippo@gmx.de> - 2016-12-15 22:40 +0100
Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock Lino Sanfilippo <LinoSanfilippo@gmx.de> - 2016-12-15 23:40 +0100
Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock Pavel Machek <pavel@ucw.cz> - 2016-12-17 18:40 +0100
Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock Francois Romieu <romieu@fr.zoreil.com> - 2016-12-18 01:20 +0100
Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock Lino Sanfilippo <LinoSanfilippo@gmx.de> - 2016-12-18 17:20 +0100
Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock Pavel Machek <pavel@ucw.cz> - 2016-12-18 18:30 +0100
Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock Pavel Machek <pavel@ucw.cz> - 2016-12-18 19:40 +0100
Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock Lino Sanfilippo <LinoSanfilippo@gmx.de> - 2016-12-19 23:50 +0100
Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock Pavel Machek <pavel@ucw.cz> - 2016-12-18 21:20 +0100
Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock Pavel Machek <pavel@ucw.cz> - 2016-12-19 11:10 +0100
Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock Francois Romieu <romieu@fr.zoreil.com> - 2016-12-20 01:10 +0100
csiph-web