Pradeep
2009-Sep-15 14:56 UTC
[crossbow-discuss] buffers not returing from stack (gldv3 network driver)
Hi , Iam developing a gldv3 network driver , i often face problems while detaching my module . When heavy traffic is running on that interface and if i try to remove the module i end up some buffers not being returned from the stack . I am failing detach during this buffer held condition . But is there any way to push the stack to return the completions In between i use desballoc for the receive buffers allocation Thanks in Advance Pradeep G -- This message posted from opensolaris.org
Kais Belgaied
2009-Sep-15 16:45 UTC
[crossbow-discuss] buffers not returing from stack (gldv3 network driver)
Pradeep, the buffers could also be tied up in the socket layer, waiting for an application to either complete reading or close the socket and free all messages thus releasing all buffers. I''m forwarding this question to the wider networking discuss for possible other comments. Kais,. On 09/15/09 07:56, Pradeep wrote:> Hi , > Iam developing a gldv3 network driver , i often face problems > while detaching my module . When heavy traffic is running on that > interface and if i try to remove the module i end up some buffers not > being returned from the stack . I am failing detach during this buffer held > condition . But is there any way to push the stack to return the completions > > In between i use desballoc for the receive buffers allocation > > Thanks in Advance > Pradeep G >
Jason King
2009-Sep-15 18:58 UTC
[crossbow-discuss] [networking-discuss] buffers not returing from stack (gldv3 network driver)
On Tue, Sep 15, 2009 at 11:45 AM, Kais Belgaied <Kais.Belgaied at sun.com> wrote:> Pradeep, > > the buffers could also be tied up in the socket layer, waiting for an > application to either > complete reading or close the socket and free all messages thus releasing > all buffers. > > I''m forwarding this question to the wider networking discuss for possible > other comments. > > Kais,. > > On 09/15/09 07:56, Pradeep wrote: >> >> Hi , >> ? ? Iam developing a gldv3 network driver , i often face problems >> while detaching my module . When heavy traffic is running on that >> interface and if i try to remove the module i end up some buffers not >> being returned from the stack . I am failing detach during this buffer >> held >> condition . But is there any way to push the stack to return the >> completions >> >> In between i use desballoc for the receive buffers allocation >> >> Thanks in Advance >> Pradeep G >>Perhaps I just haven''t thought about enough, but just off the top of my head, as there been any consideration for a framework for managing/reusing buffers specifically geared towards network drivers?
Garrett D''Amore
2009-Sep-15 19:06 UTC
[crossbow-discuss] [networking-discuss] buffers not returing from stack (gldv3 network driver)
Jason King wrote:> On Tue, Sep 15, 2009 at 11:45 AM, Kais Belgaied <Kais.Belgaied at sun.com> wrote: > >> Pradeep, >> >> the buffers could also be tied up in the socket layer, waiting for an >> application to either >> complete reading or close the socket and free all messages thus releasing >> all buffers. >> >> I''m forwarding this question to the wider networking discuss for possible >> other comments. >> >> Kais,. >> >> On 09/15/09 07:56, Pradeep wrote: >> >>> Hi , >>> Iam developing a gldv3 network driver , i often face problems >>> while detaching my module . When heavy traffic is running on that >>> interface and if i try to remove the module i end up some buffers not >>> being returned from the stack . I am failing detach during this buffer >>> held >>> condition . But is there any way to push the stack to return the >>> completions >>> >>> In between i use desballoc for the receive buffers allocation >>> >>> Thanks in Advance >>> Pradeep G >>> >>> > > Perhaps I just haven''t thought about enough, but just off the top of > my head, as there been any consideration for a framework for > managing/reusing buffers specifically geared towards network drivers? >Yes. I''ve thought about it, and another engineer inside Sun is working on one. Can''t remember the name of the person right now... but I''ve looked at some design doco. - Garrett> _______________________________________________ > crossbow-discuss mailing list > crossbow-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss >
Jason King
2009-Sep-15 19:12 UTC
[crossbow-discuss] [networking-discuss] buffers not returing from stack (gldv3 network driver)
On Tue, Sep 15, 2009 at 2:06 PM, Garrett D''Amore <garrett at damore.org> wrote:> Jason King wrote: >> >> On Tue, Sep 15, 2009 at 11:45 AM, Kais Belgaied <Kais.Belgaied at sun.com> >> wrote: >> >>> >>> Pradeep, >>> >>> the buffers could also be tied up in the socket layer, waiting for an >>> application to either >>> complete reading or close the socket and free all messages thus releasing >>> all buffers. >>> >>> I''m forwarding this question to the wider networking discuss for possible >>> other comments. >>> >>> Kais,. >>> >>> On 09/15/09 07:56, Pradeep wrote: >>> >>>> >>>> Hi , >>>> ? ?Iam developing a gldv3 network driver , i often face problems >>>> while detaching my module . When heavy traffic is running on that >>>> interface and if i try to remove the module i end up some buffers not >>>> being returned from the stack . I am failing detach during this buffer >>>> held >>>> condition . But is there any way to push the stack to return the >>>> completions >>>> >>>> In between i use desballoc for the receive buffers allocation >>>> >>>> Thanks in Advance >>>> Pradeep G >>>> >>>> >> >> Perhaps I just haven''t thought about enough, but just off the top of >> my head, as there been any consideration for a framework for >> managing/reusing buffers specifically geared towards network drivers? >> > > Yes. ?I''ve thought about it, and another engineer inside Sun is working on > one. ?Can''t remember the name of the person right now... but I''ve looked at > some design doco.Excellent.. hopefully at some point we''ll be able to take a look (or even assist)
Min Miles Xu
2009-Sep-16 04:51 UTC
[crossbow-discuss] [networking-discuss] buffers not returing from stack (gldv3 network driver)
Jason King wrote:> On Tue, Sep 15, 2009 at 2:06 PM, Garrett D''Amore <garrett at damore.org> wrote: > >> Jason King wrote: >> >>> On Tue, Sep 15, 2009 at 11:45 AM, Kais Belgaied <Kais.Belgaied at sun.com> >>> wrote: >>> >>> >>>> Pradeep, >>>> >>>> the buffers could also be tied up in the socket layer, waiting for an >>>> application to either >>>> complete reading or close the socket and free all messages thus releasing >>>> all buffers. >>>> >>>> I''m forwarding this question to the wider networking discuss for possible >>>> other comments. >>>> >>>> Kais,. >>>> >>>> On 09/15/09 07:56, Pradeep wrote: >>>> >>>> >>>>> Hi , >>>>> Iam developing a gldv3 network driver , i often face problems >>>>> while detaching my module . When heavy traffic is running on that >>>>> interface and if i try to remove the module i end up some buffers not >>>>> being returned from the stack . I am failing detach during this buffer >>>>> held >>>>> condition . But is there any way to push the stack to return the >>>>> completions >>>>> >>>>> In between i use desballoc for the receive buffers allocation >>>>> >>>>> Thanks in Advance >>>>> Pradeep G >>>>> >>>>> >>>>> >>> Perhaps I just haven''t thought about enough, but just off the top of >>> my head, as there been any consideration for a framework for >>> managing/reusing buffers specifically geared towards network drivers? >>> >>> >> Yes. I''ve thought about it, and another engineer inside Sun is working on >> one. Can''t remember the name of the person right now... but I''ve looked at >> some design doco. >> > > Excellent.. hopefully at some point we''ll be able to take a look (or > even assist) >I''m not sure if "another engineer" Garrett mentioned is me or not. I''ve been working on one framework. It can relieve the issue discussed, eliminating the complexities for drivers to handle buffers not returned. It''s the initial aim when I started the work. And as the time goes by, it''s more than that, a number of features/optimizations are added in. I keep updating the design these days. I expect to hand it for reviews at some point. Regards, Miles Xu