Re: E1000 mbuf leaks

2015-07-30 Thread hiren panchasara
On 07/27/15 at 01:02P, Hans Petter Selasky wrote:
> Hi,
> 
> I'm currently doing some busdma work, and possibly stepped over some 
> driver bugs. When "bus_dmamap_load_mbuf_sg()" returns ENOMEM the mbuf 
> chain is not freed. Is there some magic in "bus_dmamap_load_mbuf_sg()" 
> for that error code or is there a possible memory leak in all E1000 
> drivers? See attached patch.

Can you open a phabricator review if this hasn't been reviewed/committed
yet?

cheers,
Hiren


pgpJXdQwQgkIL.pgp
Description: PGP signature


Re: E1000 mbuf leaks

2015-07-27 Thread Ben Woods
On Monday, July 27, 2015, Hans Petter Selasky  wrote:

> Hi,
>
> I'm currently doing some busdma work, and possibly stepped over some
> driver bugs. When "bus_dmamap_load_mbuf_sg()" returns ENOMEM the mbuf chain
> is not freed. Is there some magic in "bus_dmamap_load_mbuf_sg()" for that
> error code or is there a possible memory leak in all E1000 drivers? See
> attached patch.


Would this explain the high mbuf usage seen on pfsense when using the
igb(4) or em(4) Intel NIC drivers?


https://doc.pfsense.org/index.php/Tuning_and_Troubleshooting_Network_Cards#Intel_igb.284.29_and_em.284.29_Cards

Regards,
Ben


-- 

--
From: Benjamin Woods
woods...@gmail.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: E1000 mbuf leaks

2015-07-27 Thread Yonghyeon PYUN
On Mon, Jul 27, 2015 at 01:02:32PM +0200, Hans Petter Selasky wrote:
> Hi,
> 
> I'm currently doing some busdma work, and possibly stepped over some 
> driver bugs. When "bus_dmamap_load_mbuf_sg()" returns ENOMEM the mbuf 
> chain is not freed. Is there some magic in "bus_dmamap_load_mbuf_sg()" 
> for that error code or is there a possible memory leak in all E1000 
> drivers? See attached patch.

I don't think it's an mbuf leak since lem(4) just prepend the mbuf
to the if sendq(driver will retry it later).  But I think your
patch looks more correct in bus_dma(9) perspective.  If
bus_dmamap_load_mbuf_sg(9) returned an error except EFBIG, it would
be correct for lem(4) to free the mbuf chains rather than
restarting the bus_dmamap_load_mbuf_sg(9) later which shall fail
again with ENOMEM.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"