Skip to contentSkip to conversation

net: qualcomm: rmnet: Support recycling frames to real device

PATCH In review Subash Abhinov Kasiviswanathan 3 participants 5 messages Oct 27, 2017 – Nov 1, 2017

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

PATCH 1/1 net: qualcomm: rmnet: Support recycling frames to real device

For deaggregation, the real device receives a large linear skb and passes it on to rmnet. rmnet creates new skbs from this large frame.

If the real device supports recycling, it does not need to allocate the large skbs during packet reception and can instead reuse them.

---
 drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c +4 -1
index 29842cc..7869fcf 100644
@@ -108,7 +108,10 @@ static void rmnet_set_skb_proto(struct sk_buff *skb)
 		while ((skbn = rmnet_map_deaggregate(skb)) != NULL)
 			__rmnet_map_ingress_handler(skbn, port);
 
-		consume_skb(skb);
+		if (skb->destructor)
+			skb->destructor(skb);
+		else
+			consume_skb(skb);
 	} else {
 		__rmnet_map_ingress_handler(skb, port);
 	}
Signature · 1 line
1.9.1
#1 lore raw
Quoted 17 lines · Subash Abhinov Kasiviswanathan

For deaggregation, the real device receives a large linear skb and passes it on to rmnet. rmnet creates new skbs from this large frame.

If the real device supports recycling, it does not need to allocate the large skbs during packet reception and can instead reuse them.

---
 drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c +0 -0
index 29842cc..7869fcf 100644
@@ -108,7 +108,10 @@ static void rmnet_set_skb_proto(struct sk_buff *skb)
                while ((skbn = rmnet_map_deaggregate(skb)) != NULL)

drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c static void rmnet_set_skb_proto(struct sk_buff *skb) · line 117

Quoted 10 lines
drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c +4 -1
                        __rmnet_map_ingress_handler(skbn, port);
 
-               consume_skb(skb);
+               if (skb->destructor)
+                       skb->destructor(skb);
+               else
+                       consume_skb(skb);
        } else {
                __rmnet_map_ingress_handler(skb, port);
        }

This doesn't make sense to me, maybe I am missing something. What "real device" is setting the skb->destructor() and doing it to somehow handle recycling? The only driver I can find that is setting skb->desctructor() is the Chelsio drivers, and they appear to be using it to just clean-up DMA mappings in their transmit path.

Thanks.

- Alex

#2 lore raw
Quoted 9 lines

This doesn't make sense to me, maybe I am missing something. What "real device" is setting the skb->destructor() and doing it to somehow handle recycling? The only driver I can find that is setting skb->desctructor() is the Chelsio drivers, and they appear to be using it to just clean-up DMA mappings in their transmit path.

Thanks.

- Alex

Hi Alex

The real device will have a pool of skbs and mark them as unused on initialization. It will use these skbs to copy data from hardware and pass them onto rmnet after marking them as used. Once rmnet is done processing, the callback of the real device set in the skb_destructor is invoked and the skb is set as unused and can be used again for copying data.

There are no drivers setting the skb->destructor() in receive path upstream as of now but the plan is to get them there.

Signature · 2 lines
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
#3 lore raw
Quoted 11 lines · Subash Abhinov Kasiviswanathan
Quoted 9 lines

This doesn't make sense to me, maybe I am missing something. What "real device" is setting the skb->destructor() and doing it to somehow handle recycling? The only driver I can find that is setting skb->desctructor() is the Chelsio drivers, and they appear to be using it to just clean-up DMA mappings in their transmit path.

Thanks.

- Alex

Quoted 8 lines

Hi Alex

The real device will have a pool of skbs and mark them as unused on initialization. It will use these skbs to copy data from hardware and pass them onto rmnet after marking them as used. Once rmnet is done processing, the callback of the real device set in the skb_destructor is invoked and the skb is set as unused and can be used again for copying data.

There is a pretty big difference between calling skb->destructor() and freeing the buffer. My concern would be how do you deal with the reference count issues that is going to bring up?

Quoted 2 lines

There are no drivers setting the skb->destructor() in receive path upstream as of now but the plan is to get them there.

Okay. Got it.

Thanks.

- Alex

maintainer
#4 lore raw
In reply to Subash Abhinov Kasiviswanathan

From: Subash Abhinov Kasiviswanathan <[email protected]>
Date: Fri, 27 Oct 2017 14:30:08 -0600

Quoted 7 lines

For deaggregation, the real device receives a large linear skb and passes it on to rmnet. rmnet creates new skbs from this large frame.

If the real device supports recycling, it does not need to allocate the large skbs during packet reception and can instead reuse them.

I'm uncomfortable applying this until you also provide an example of this skb->destructor mechanism actually being used in a driver.

Thank you.