DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: "Assaad, Sami (Sami)" <sami.assaad@alcatel-lucent.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] DPDK Port Mirroring
Date: Fri, 10 Jul 2015 15:36:44 +0100	[thread overview]
Message-ID: <20150710143644.GB7824@bricha3-MOBL3> (raw)
In-Reply-To: <9478F0FB69DAA249AF0A9BDA1E6ED952188498CA@US70TWXCHMBA07.zam.alcatel-lucent.com>

On Fri, Jul 10, 2015 at 02:21:08PM +0000, Assaad, Sami (Sami) wrote:
> Now; what if we are to encapsulate the packet within a tunnel; such as GRE, prior to sending it out to a mirrored-port ... Must the packet be copied into a new buffer or can we use a DPDK primitive that is more efficient?
> 
> Sami.

You don't necessarily need to copy the whole packet, since mbufs can be created
that point to other mbufs. 

Two ways of doing this, assuming the original packet is unmodified. You can create
a chain of mbufs where the first mbuf contains the extra headers, and then its
"next" pointer points to the original mbuf (Updating the reference count while
it's doing so).

Second, there is the mbuf attach function (which will update the refcnt for you)
where you end up with a second mbuf where the data area belongs to the first.
Then you can use prepend on the second mbuf to stick the extra headers on the
front of the packet, while leaving the original mbuf pointing beyond those
headers still.

Either of these, or some varient thereof should work for you. If you do need to
modify the shared headers between the two ports, some data copying of the headers
may be necessary, but you should never really need to copy the entire packet.

/Bruce

> 
> > -----Original Message-----
> > From: Bruce Richardson [mailto:bruce.richardson@intel.com] 
> > Sent: Friday, July 10, 2015 9:48 AM
> > To: Sanford, Robert
> > Cc: Matt Laswell; Wiles, Keith; dev@dpdk.org; Assaad, Sami (Sami)
> > Subject: Re: [dpdk-dev] DPDK Port Mirroring
> 
> > On Fri, Jul 10, 2015 at 01:46:21PM +0000, Sanford, Robert wrote:
> > > Silly questions: Why use rte_pktmbuf_clone()? Assuming that one is not 
> > > going to modify the mbuf at all, why not just increment the reference 
> > > count with rte_mbuf_refcnt_update()?
> > > 
> > Yep, that should work fine too.
> >
> > /Bruce
> > > --
> > > Thanks,
> > > Robert
> > > 
> > > 
> > > >Keith speaks truth.  If I were going to do what you're describing, I 
> > > >would do the following:
> > > >
> > > >1. Start with the l2fwd example application.
> > > >2. Remove the part where it modifies the ethernet MAC address of 
> > > >received packets.
> > > >3. Add a call in to clone mbufs via rte_pktmbuf_clone() and send the 
> > > >cloned packets out of the port of your choice
> > > >
> > > >As long as you don't need to modify the packets - and if you're 
> > > >mirroring, you shouldn't - simply cloning received packets and 
> > > >sending them out your mirror port should get you most of the way there.
> > > >
> > > >On Thu, Jul 9, 2015 at 3:17 PM, Wiles, Keith <keith.wiles@intel.com>
> > > >wrote:
> > > >
> > > >>
> > > >>
> > > >> On 7/9/15, 12:26 PM, "dev on behalf of Assaad, Sami (Sami)"
> > > >> <dev-bounces@dpdk.org on behalf of sami.assaad@alcatel-lucent.com>
> > > >>wrote:
> > > >>
> > > >> >Hello,
> > > >> >
> > > >> >I want to build a DPDK app that is able to port-mirror all ingress 
> > > >> >traffic from two 10G interfaces.
> > > >> >
> > > >> >1.       Is it possible in port-mirroring traffic consisting of 450byte
> > > >> >packets at 20G without losing more than 5% of traffic?
> > > >> >
> > > >> >2.       Would you have any performance results due to packet copying?
> > > >>
> > > >> Do you need to copy the packet if you increment the reference count 
> > > >> you can send the packet to both ports without having to copy the packet.
> > > >> >
> > > >> >3.       Would you have any port mirroring DPDK sample code?
> > > >>
> > > >> DPDK does not have port mirroring example, but you could grab the 
> > > >>l2fwd or  l3fwd and modify it to do what you want.
> > > >> >
> > > >> >Thanks in advance.
> > > >> >
> > > >> >Best Regards,
> > > >> >Sami Assaad.
> > > >>
> > > >>
> > > 

  reply	other threads:[~2015-07-10 14:36 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-09 20:17 Wiles, Keith
2015-07-09 20:27 ` Matt Laswell
2015-07-09 20:30   ` Assaad, Sami (Sami)
2015-07-10 13:46   ` Sanford, Robert
2015-07-10 13:47     ` Bruce Richardson
2015-07-10 14:21       ` Assaad, Sami (Sami)
2015-07-10 14:36         ` Bruce Richardson [this message]
  -- strict thread matches above, loose matches on Subject: below --
2015-07-09 17:26 Assaad, Sami (Sami)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150710143644.GB7824@bricha3-MOBL3 \
    --to=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=sami.assaad@alcatel-lucent.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).