Skip to contentSkip to conversation

S2io: NAPI fix

PATCH In review Ravinandan Arakali 3 participants 4 messages Oct 14, 2004 – Oct 15, 2004

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 7/8 S2io: NAPI fix

Hi,
This patch contains the following NAPI related fixes.

1. When processing Rx packets, making sure that get offset of ring does not cross the put
offset.

2. when NAPI is not in use a new spinlock(put_lock) is used to make sure accessing put
offset of ring is atomic.

3. Also introduced a new vaiable put_pos in nic_t to keep track of absolute position of the
put pointer of Rx ring.

4. When NAPI is used, fill_rx_buffer is not called from the interrupt handler(s2io_isr) .

5. In s2io_poll, decrementing packets processed is done inside the while loop unlike out
side it as was being done last time.

#1 lore raw

Comments on patch #7:

1) Can you prove that put_lock is really necessary, and not covered by other methods of synchronization? Typically the preferred model is that your RX process requires _no_ spinlocks, and instead you use the net stack API to ensure when your RX process is, and is not, running.

otherwise, no objections to this patch

#2 lore raw

Hi Jeff,

My comments inline.

Quoted 8 lines

-----Original Message-----
From: Jeff Garzik [mailto:[email protected]]
Sent: Thursday, October 14, 2004 8:00 AM
To: [email protected]
Cc: 'Francois Romieu'; [email protected]; [email protected]; [email protected]; [email protected]
Subject: Re: [PATCH 2.6.9-rc2 7/8] S2io: NAPI fix

Quoted 7 lines

Comments on patch #7:

1) Can you prove that put_lock is really necessary, and not covered by other methods of synchronization? Typically the preferred model is that your RX process requires _no_ spinlocks, and instead you use the net stack API to ensure when your RX process is, and is not, running.

<KSK>
Lets say, CPU0 after processing s2io_isr, schedules s2io_tasklet.
The tasklet in turn calls fill_rx_buffer which will replenish skbs into Rx descriptors and start modifying the put index of the Rx ring, at the same time if there is another Rx interrupt being processed (rx_intr_handler) on CPU1, then it will try to read put index of the ring which can result in synchronization problem. So I created this new variable put_pos to track the absolute value of the put index and make sure all its accesses are between spin locks. The same problem cannot happen if NAPI is used since the s2io_poll and fill_rx_buffer calls are serialized.

-Koushik

Quoted 1 line

otherwise, no objections to this patch

#3 lore raw
Quoted 21 lines · Raghavendra Koushik

Hi Jeff,

My comments inline.

Quoted 8 lines

-----Original Message-----
From: Jeff Garzik [mailto:[email protected]]
Sent: Thursday, October 14, 2004 8:00 AM
To: [email protected]
Cc: 'Francois Romieu'; [email protected]; [email protected]; [email protected]; [email protected]
Subject: Re: [PATCH 2.6.9-rc2 7/8] S2io: NAPI fix

Quoted 7 lines

Comments on patch #7:

1) Can you prove that put_lock is really necessary, and not covered by other methods of synchronization? Typically the preferred model is that your RX process requires _no_ spinlocks, and instead you use the net stack API to ensure when your RX process is, and is not, running.

Quoted 10 lines

<KSK>
Lets say, CPU0 after processing s2io_isr, schedules s2io_tasklet.
The tasklet in turn calls fill_rx_buffer which will replenish skbs into Rx descriptors and start modifying the put index of the Rx ring, at the same time if there is another Rx interrupt being processed (rx_intr_handler) on CPU1, then it will try to read put index of the ring which can result in synchronization problem. So I created this new variable put_pos to track the absolute value of the put index and make sure all its accesses are between spin locks. The same problem cannot happen if NAPI is used since the s2io_poll and fill_rx_buffer calls are serialized.

Have you actually benchmarked this on SMP?

It seems to me that you pay a penalty cross-CPU traffic with this scheme?

Jeff