On Thu, Mar 15, 2018 at 9:27 AM, Sinan Kaya wrote:
> On 3/15/2018 12:21 PM, Sinan Kaya wrote:
>> On 3/15/2018 10:32 AM, Alexander Duyck wrote:
>>> We tend to do something like:
>>> update tx_buffer_info
>>> update tx_desc
>>> wmb()
>>> point first tx_buffer_info next_to_watch value at last
On 3/15/2018 12:21 PM, Sinan Kaya wrote:
> On 3/15/2018 10:32 AM, Alexander Duyck wrote:
>> We tend to do something like:
>> update tx_buffer_info
>> update tx_desc
>> wmb()
>> point first tx_buffer_info next_to_watch value at last tx_desc
>> update next_to_use
>> notify device via writ
On 3/15/2018 10:32 AM, Alexander Duyck wrote:
> We tend to do something like:
> update tx_buffer_info
> update tx_desc
> wmb()
> point first tx_buffer_info next_to_watch value at last tx_desc
> update next_to_use
> notify device via writel
>
> We do it this way because we have to synch
On Wed, Mar 14, 2018 at 7:17 PM, Sinan Kaya wrote:
> On 3/14/2018 9:44 PM, Alexander Duyck wrote:
>> On Wed, Mar 14, 2018 at 3:57 PM, Sinan Kaya wrote:
>>> Hi Alexander,
>>>
>>> On 3/14/2018 5:49 PM, Alexander Duyck wrote:
On Wed, Mar 14, 2018 at 5:13 AM, wrote:
> On 2018-03-14 01:08,
On 3/14/2018 9:44 PM, Alexander Duyck wrote:
> On Wed, Mar 14, 2018 at 3:57 PM, Sinan Kaya wrote:
>> Hi Alexander,
>>
>> On 3/14/2018 5:49 PM, Alexander Duyck wrote:
>>> On Wed, Mar 14, 2018 at 5:13 AM, wrote:
On 2018-03-14 01:08, Timur Tabi wrote:
>
> On 3/13/18 10:20 PM, Sinan Kay
On Tue, Mar 13, 2018 at 8:20 PM, Sinan Kaya wrote:
> Code includes wmb() followed by writel() in multiple places. writel()
> already has a barrier on some architectures like arm64.
>
> This ends up CPU observing two barriers back to back before executing the
> register write.
>
> Since code alread
On Wed, Mar 14, 2018 at 3:57 PM, Sinan Kaya wrote:
> Hi Alexander,
>
> On 3/14/2018 5:49 PM, Alexander Duyck wrote:
>> On Wed, Mar 14, 2018 at 5:13 AM, wrote:
>>> On 2018-03-14 01:08, Timur Tabi wrote:
On 3/13/18 10:20 PM, Sinan Kaya wrote:
>
>> Actually I would argue this whole patch
Hi Alexander,
On 3/14/2018 5:49 PM, Alexander Duyck wrote:
> On Wed, Mar 14, 2018 at 5:13 AM, wrote:
>> On 2018-03-14 01:08, Timur Tabi wrote:
>>>
>>> On 3/13/18 10:20 PM, Sinan Kaya wrote:
> Actually I would argue this whole patch set is pointless. For starters
> why is it we are only updating
On Wed, Mar 14, 2018 at 5:13 AM, wrote:
> On 2018-03-14 01:08, Timur Tabi wrote:
>>
>> On 3/13/18 10:20 PM, Sinan Kaya wrote:
>>>
>>> +/* Assumes caller has executed a write barrier to order memory and
>>> device
>>> + * requests.
>>> + */
>>> static inline void ixgbevf_write_tail(struct ixgbev
On 2018-03-14 01:08, Timur Tabi wrote:
On 3/13/18 10:20 PM, Sinan Kaya wrote:
+/* Assumes caller has executed a write barrier to order memory and
device
+ * requests.
+ */
static inline void ixgbevf_write_tail(struct ixgbevf_ring *ring, u32
value)
{
- writel(value, ring->tail);
+
On 3/13/18 10:20 PM, Sinan Kaya wrote:
+/* Assumes caller has executed a write barrier to order memory and device
+ * requests.
+ */
static inline void ixgbevf_write_tail(struct ixgbevf_ring *ring, u32 value)
{
- writel(value, ring->tail);
+ writel_relaxed(value, ring->tail);
}
Code includes wmb() followed by writel() in multiple places. writel()
already has a barrier on some architectures like arm64.
This ends up CPU observing two barriers back to back before executing the
register write.
Since code already has an explicit barrier call, changing writel() to
writel_rela
12 matches
Mail list logo
