From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx01.arubanetworks.com (mx01.arubanetworks.com [104.36.248.59]) by dpdk.org (Postfix) with ESMTP id 2A7155A82 for ; Fri, 16 Jan 2015 08:17:15 +0100 (CET) X-ASG-Debug-ID: 1421392632-03d124379c72aca0001-TfluYd Received: from sjc-exch10hc-02.arubanetworks.com (sjc-exch10hc-02.arubanetworks.com [10.1.8.46]) by mx01.arubanetworks.com with ESMTP id Sr2zBijfGZ0Q4BAL (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 15 Jan 2015 23:17:12 -0800 (PST) X-Barracuda-Envelope-From: vmohare@arubanetworks.com Received: from BOREAL.arubanetworks.com ([fe80::19f0:d3af:7377:a759]) by sjc-exch10hc-02.arubanetworks.com ([fe80::88ce:11e3:e0a3:1489%16]) with mapi id 14.03.0158.001; Thu, 15 Jan 2015 23:17:12 -0800 From: Vithal S Mohare To: "dev@dpdk.org" Thread-Topic: Callbacks after buffer (mbuf) sent out X-ASG-Orig-Subj: RE: Callbacks after buffer (mbuf) sent out Thread-Index: AdAu40Enj1lEEOL2T4SKZboH13yjggCeDahQ Date: Fri, 16 Jan 2015 07:17:11 +0000 Message-ID: <98DB008FA2AC6644B40AD8C766FAB271014BDE87EE@BOREAL.arubanetworks.com> References: <98DB008FA2AC6644B40AD8C766FAB271014BDE7723@BOREAL.arubanetworks.com> In-Reply-To: <98DB008FA2AC6644B40AD8C766FAB271014BDE7723@BOREAL.arubanetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.22.62] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: sjc-exch10hc-02.arubanetworks.com[10.1.8.46] X-Barracuda-Start-Time: 1421392632 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: https://mx01.arubanetworks.com:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at arubanetworks.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=7.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.14337 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Subject: Re: [dpdk-dev] Callbacks after buffer (mbuf) sent out X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2015 07:17:15 -0000 To elaborate more... Assuming an example of vmxnet3 driver, at present, when rte_eth_tx_burst() = is called to send mbufs, vmxnet3 driver calls vmxnet3_tq_tx_complete() to f= ree up completed buffers. Instead, wondering, if vmxnet3 (or correspondin= g driver) can trigger application callback for the buffer (mbuf) which gets= transmitted out of n/w interface. Application callback can decide now dec= ide whether to reuse the mbuf and continue multicasting on other tunnels. = =20 Thanks, -Vithal -----Original Message----- From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Vithal S Mohare Sent: Tuesday, January 13, 2015 9:21 AM To: dev@dpdk.org Subject: [dpdk-dev] Callbacks after buffer (mbuf) sent out Hi, I am looking for application callbacks after mbufs are sent (tx) out succes= sfully. One of the use cases is for async multicast (over different gre t= unnels etc). Using direct/indirect buffers along with ref-count itself is= not enough, as actual 'pkt-data' itself changes while flooding on list of = tunnels. Thanks, -Vithal