Message ID | 1509136208-14768-1-git-send-email-subashab@codeaurora.org |
---|---|
State | Changes Requested, archived |
Delegated to: | David Miller |
Headers | show |
Series | [net-next] net: qualcomm: rmnet: Support recycling frames to real device | expand |
On Fri, Oct 27, 2017 at 1:30 PM, Subash Abhinov Kasiviswanathan <subashab@codeaurora.org> wrote: > 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 <subashab@codeaurora.org> > --- > drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c b/drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c > index 29842cc..7869fcf 100644 > --- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c > +++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c > @@ -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); > } 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
> 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.
On Fri, Oct 27, 2017 at 3:22 PM, Subash Abhinov Kasiviswanathan <subashab@codeaurora.org> wrote: >> 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 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? > 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
From: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org> Date: Fri, 27 Oct 2017 14:30:08 -0600 > 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 <subashab@codeaurora.org> I'm uncomfortable applying this until you also provide an example of this skb->destructor mechanism actually being used in a driver. Thank you.
diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c b/drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c index 29842cc..7869fcf 100644 --- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c +++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c @@ -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); }
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 <subashab@codeaurora.org> --- drivers/net/ethernet/qualcomm/rmnet/rmnet_handlers.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)