net: qualcomm: rmnet: Support recycling frames to real device
Subsystems (3)
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
@@ -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
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.
Signed-off-by Subash Abhinov Kasiviswanathan <[email protected]>--- 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@@ -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
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 settingskb->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
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 settingskb->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_destructoris 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
David Miller
maintainerFrom: 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.
Signed-off-by Subash Abhinov Kasiviswanathan <[email protected]>
I'm uncomfortable applying this until you also provide an example of this skb->destructor mechanism actually being used in a driver.
Thank you.