DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Liu, Jijiang" <jijiang.liu@intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v6 2/9] librte_ether:add VxLAN packet identification API in librte_ether
Date: Wed, 22 Oct 2014 12:47:08 +0000	[thread overview]
Message-ID: <1ED644BD7E0A5F4091CF203DAFB8E4CC01D82A66@SHSMSX101.ccr.corp.intel.com> (raw)
In-Reply-To: <6121673.LPIm1x7VbG@xps13>



> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Wednesday, October 22, 2014 5:52 PM
> To: Liu, Jijiang
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v6 2/9] librte_ether:add VxLAN packet
> identification API in librte_ether
> 
> 2014-10-22 01:46, Liu, Jijiang:
> > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > > 2014-10-21 13:48, Liu, Jijiang:
> > > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > > > > But I doubt we should configure a tunnel type for a whole port.
> > > >
> > > > Yes, your understanding is correct. It is for a whole port/PF,
> > > > that's why we should add tunnel_type in rte_eth_conf structure.
> > >
> > > Please explain me why a tunnel type should be associated to a port.
> > > This design looks really broken.
> >
> > I don't think this design looks really broken.
> >
> > Currently, A PF  associated to a port, right? What tunnel type should
> > be supported in a PF, which is required we configure it.
> > Tunneling packet is encapsulation packet, in terms of VxLAN, packet
> > format is outer L2 header+ outer L3 header +outer L4 header +
> > tunneling header+ inner L2 header + inner L3 header + inner L4 header
> +PAY4.
> > For a VM/VF, the  real useful packet data is "inner L2 header + inner
> > L3 header + inner L4 header +PAY4".
> >
> > In NIC, A port/PF receive this kind of tunneling packet(outer
> > L2+...PAY4), software should be responsible for decapsulating the
> > packet and deliver real data(innerL2 + PAY4) to VM/VF。
> >
> > DPDK just provide API/mechanism to guarantee a PF/port to receive the
> > tunneling packet data, the encapsulation/ decapsulation work should be
> > done by user application.
> 
> You mean that all packets received on the PF which doesn't match the
> configured tunnel type, won't be received by the software?

No, it will be received by the software.
In terms of VxLAN packet, if tunnel type is not configured VXLAN type, and software can't use API to configure the UDP destination number. 
Even if the incoming packet format is VXLAN packet format, hardware and software don't think it is VXLAN packet because we didn't configure UDP Destination port. 

Now I want to remove this limitation,  even if the  tunnel type is not configured at PF initialization phase, user also can configure the VxLAN UDP destination number.
It is more flexible and reasonable.

> Other question, why a port is associated with only one tunnel type?

Good question. Now I think we had better remove this limitation because it is NIC related.

Two points are summarized here.
1. The tunnel types is for a whole port/PF, I have explained it a lots.
2. I will remove tunnel type configuration from rte_eth_conf structure.

Any comments?

> > Normally, the tunneling packet processing like below:
> > Tunneling packet ------>PF processing/receive ---------> application
> > SW do decapsulation -------> VF/VM processing
> 
> I really try to understand what you have in mind. Thanks for explaining
> --
> Thomas

  reply	other threads:[~2014-10-22 12:38 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-21  8:45 [dpdk-dev] [PATCH v6 0/9] Support VxLAN on Fortville Jijiang Liu
2014-10-21  8:46 ` [dpdk-dev] [PATCH v6 1/9] librte_mbuf:the rte_mbuf structure changes Jijiang Liu
2014-10-21 10:26   ` Thomas Monjalon
2014-10-21 14:14     ` Liu, Jijiang
2014-10-22  8:45       ` Thomas Monjalon
2014-10-22  8:53         ` Liu, Jijiang
2014-10-23  2:23         ` Zhang, Helin
2014-11-12 13:26           ` Thomas Monjalon
2014-11-12 14:31             ` Zhang, Helin
2014-11-12 15:23               ` Thomas Monjalon
2014-11-13  3:17             ` Liu, Jijiang
2014-11-13  8:53               ` Thomas Monjalon
2014-11-13 11:24                 ` Liu, Jijiang
2014-11-13 11:35                   ` Thomas Monjalon
2014-10-21  8:46 ` [dpdk-dev] [PATCH v6 2/9] librte_ether:add VxLAN packet identification API in librte_ether Jijiang Liu
2014-10-21 10:51   ` Thomas Monjalon
2014-10-21 13:48     ` Liu, Jijiang
2014-10-21 21:19       ` Thomas Monjalon
2014-10-22  1:46         ` Liu, Jijiang
2014-10-22  9:52           ` Thomas Monjalon
2014-10-22 12:47             ` Liu, Jijiang [this message]
2014-10-22 13:25               ` Thomas Monjalon
2014-10-22  5:21         ` Liu, Jijiang
2014-10-21  8:46 ` [dpdk-dev] [PATCH v6 3/9] i40e:support VxLAN packet identification in librte_pmd_i40e Jijiang Liu
2014-10-21  8:46 ` [dpdk-dev] [PATCH v6 4/9] app/test-pmd:test VxLAN packet identification Jijiang Liu
2014-10-21  8:46 ` [dpdk-dev] [PATCH v6 5/9] librte_ether:add data structures of VxLAN filter Jijiang Liu
2014-10-21 15:13   ` Thomas Monjalon
2014-10-22  2:25     ` Liu, Jijiang
2014-10-22  9:31       ` Thomas Monjalon
2014-10-22 11:03         ` Liu, Jijiang
2014-10-23  9:06           ` Chilikin, Andrey
2014-10-22  6:45     ` Liu, Jijiang
2014-10-22  9:25       ` Thomas Monjalon
2014-10-22 13:54         ` Liu, Jijiang
2014-10-21  8:46 ` [dpdk-dev] [PATCH v6 6/9] i40e:implement API of VxLAN packet filter in librte_pmd_i40e Jijiang Liu
2014-10-21  8:46 ` [dpdk-dev] [PATCH v6 7/9] app/testpmd:test VxLAN packet filter Jijiang Liu
2014-10-21  8:46 ` [dpdk-dev] [PATCH v6 8/9] i40e:support VxLAN Tx checksum offload Jijiang Liu
2014-10-21  8:46 ` [dpdk-dev] [PATCH v6 9/9] app/testpmd:test " Jijiang Liu
2014-10-21 14:54 ` [dpdk-dev] [PATCH v6 0/9] Support VxLAN on Fortville Liu, Yong

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=1ED644BD7E0A5F4091CF203DAFB8E4CC01D82A66@SHSMSX101.ccr.corp.intel.com \
    --to=jijiang.liu@intel.com \
    --cc=dev@dpdk.org \
    --cc=thomas.monjalon@6wind.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).