On Sun, May 04, 2014 at 08:43:51PM +0200, Francois Romieu wrote: > Darek Marcinkiewicz <[email protected]> : > > On Sat, May 03, 2014 at 01:40:29PM +0200, Francois Romieu wrote: > [...] > > Thank you. I am attaching 2 of thse to this repsonse - the other two > > are no longer relevant due to the changes I made into the driver. > > One of the attached patches is slightly modfied by simply having one hunk > > removed (that hunk was applying to the code that was removed in next rev > > of the driver). Not sure how to proceed with those patches, shall I simply > > sent out these patches to this list as a separate messages? > > You should submit a complete series if you want them separated - git > format-patch does wonders here - or include these directly in your own > patch as I don't really care for the credit. > Ok. I've coalesced them into single patch. Thanks.
> [...] > > I have changed the code to use much modest value - it is set to be of the > > size of the fifo now. I think that this value is much better, but of course > > having this configurable would be even better. > > (see ethtool_ops.[gs]et_ringparam) > After giving it a little though I came to the consclusion that in reality it won't bring much value. So, if it is a showstopper, I would leave it at that. > [...] > > No, there is really no interrupt, hence the timer. Also on this device I > > wouldn't > > expect any bursts of data. What happens here, during regular operation of > > the > > device, is a periodic exchange of (few) ethernet packets between host cpu > > and > > terminals attached to the EtherCAT bus. As for the locking on the tx path, > > I have removed that completely on receiving path. I simply didn't know > > that it is such a big no-no here :) > > Ok. > > Regarding tx_dnext updates, you may add a short notice in ec_bhf_start_xmit > and ec_bhf_process_tx explaining that the periodic poller will somehow end > working with the right value, whence no (smp_)barrier at all. > Hmm, good point. I am not really sure that it is not a race. So, I've added memory barriers for the case when the tx ring becomes full. About to send out new patch revison. -- DM -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
