Le vendredi 02 avril 2010 à 18:28 +0200, Eric Dumazet a écrit :
quoted text
> Some more thoughts ...
> 
> Do we really want to call inet_rps_record_flow(sk) from inet_sendmsg() &
> inet_sendpage() ?
> 
> This seems not necessary to me...
> 

I think I get it, you want to catch unidirectional flows (apps that only
send data), and let ACK packets be processed by the sender cpu :=)


I did following patch to remove one conditional branch :

 net/core/dev.c |   20 +++++---------------
 1 file changed, 5 insertions(+), 15 deletions(-)


diff --git a/net/core/dev.c b/net/core/dev.c
index 0a9ced8..cfe46d8 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2225,8 +2225,6 @@ static int get_rps_cpu(struct net_device *dev, struct sk_buff *skb,
 	u16 tcpu;
 	u32 addr1, addr2, ports, ihl;
 
-	*rflowp = NULL;
-
 	if (skb_rx_queue_recorded(skb)) {
 		u16 index = skb_get_rx_queue(skb);
 		if (unlikely(index >= dev->num_rx_queues)) {
@@ -2443,7 +2441,7 @@ int netif_rx(struct sk_buff *skb)
 {
 	unsigned int qtail;
 #ifdef CONFIG_RPS
-	struct rps_dev_flow *rflow;
+	struct rps_dev_flow voidflow, *rflow = &voidflow;
 	int cpu, err;
 #endif
 
@@ -2461,10 +2459,7 @@ int netif_rx(struct sk_buff *skb)
 	if (cpu < 0)
 		cpu = smp_processor_id();
 
-	err = enqueue_to_backlog(skb, cpu, &qtail);
-
-	if (rflow)
-		rflow->last_qtail = qtail;
+	err = enqueue_to_backlog(skb, cpu, &rflow->last_qtail);
 
 	rcu_read_unlock();
 
@@ -2839,7 +2834,7 @@ out:
 int netif_receive_skb(struct sk_buff *skb)
 {
 #ifdef CONFIG_RPS
-	struct rps_dev_flow *rflow;
+	struct rps_dev_flow voidflow, *rflow = &voidflow;
 	int cpu, err;
 
 	rcu_read_lock();
@@ -2848,13 +2843,8 @@ int netif_receive_skb(struct sk_buff *skb)
 
 	if (cpu < 0)
 		err = __netif_receive_skb(skb);
-	else {
-		unsigned int qtail;
-
-		err = enqueue_to_backlog(skb, cpu, &qtail);
-		if (rflow)
-			rflow->last_qtail = qtail;
-	}
+	else
+		err = enqueue_to_backlog(skb, cpu, &rflow->last_qtail);
 
 	rcu_read_unlock();
 


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html