From: bharath paulraj <bharathpaul@gmail.com>
To: "Qiu, Michael" <michael.qiu@intel.com>
Cc: "Rose, Gregory V" <gregory.v.rose@intel.com>,
"Zhang, Helin" <helin.zhang@intel.com>,
"Lu, Wenzhuo" <wenzhuo.lu@intel.com>,
"Rowden, Aaron F" <aaron.f.rowden@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>,
"Jayakumar, Muthurajan" <muthurajan.jayakumar@intel.com>
Subject: Re: [dpdk-dev] Reg: promiscuous mode on VF
Date: Thu, 7 Apr 2016 16:09:50 +0530 [thread overview]
Message-ID: <CACfjA+nKJFUTHCKGA8HEch3JkRF7JMtXb-LvCkm9XYYuPXv2hw@mail.gmail.com> (raw)
In-Reply-To: <CACfjA+=83baq7Vm32i8g+k1CZ1R_oPkfh2mY_Rxsxab_z5CJTw@mail.gmail.com>
Hi Team,
May I have some update on my previous mail? I am here stuck in flow
creation.
Thanks,
Bharath
On Thu, Mar 31, 2016 at 4:13 PM, bharath paulraj <bharathpaul@gmail.com>
wrote:
> Hi Michael and All,
>
> I am unable to set the rule to receive the packet on the VF.
> Below is my setup.
>
> 1. Creating one virtual function with one queue, in one of my port, p2p1.
> * modprobe ixgbe MQ=1 max_vfs=1 RSS=1 allow_unsupported_sfp=1 *
> 2. Below is the interface status after creating one virtual function.
> [root@XXXX sriov]# ifconfig p2p1
> p2p1 Link encap:Ethernet HWaddr A0:36:9F:86:C2:74
> inet6 addr: fe80::a236:9fff:fe86:c274/64 Scope:Link
> UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
> RX packets:2540 errors:0 dropped:0 overruns:0 frame:0
> TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:157456 (153.7 KiB) TX bytes:258 (258.0 b)
>
> [root@XXXX sriov]# ifconfig p2p1_0
> p2p1_0 Link encap:Ethernet HWaddr DA:61:95:CD:AF:35
> inet6 addr: fe80::d861:95ff:fecd:af35/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:12 errors:0 dropped:0 overruns:0 frame:0
> TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:360 (360.0 b) TX bytes:740 (740.0 b)
> 3. Next I am enable ntuple
> *ethtool -K p2p1 ntuple on *
> 4. Now I am adding below rule
>
> *ethtool -N p2p1 flow-type udp4 dst-port 4789 action 0x100000000 --> VF
> 0, queue 0 ethtool -N p2p1 flow-type udp4 dst-port 4790 action
> 0x000000000 --> PF queue 0 *
> 5. [root@XXX sriov]# ethtool -n p2p1
> 1 RX rings available
> Total 2 rules
>
> Filter: 2044
> Rule Type: UDP over IPv4
> Src IP addr: 0.0.0.0 mask: 255.255.255.255
> Dest IP addr: 0.0.0.0 mask: 255.255.255.255
> TOS: 0x0 mask: 0xff
> Src port: 0 mask: 0xffff
> Dest port: 4790 mask: 0x0
> VLAN EtherType: 0x0 mask: 0xffff
> VLAN: 0x0 mask: 0xffff
> User-defined: 0x0 mask: 0xffffffffffffffff
> Action: Direct to queue 0
>
> Filter: 2045
> Rule Type: UDP over IPv4
> Src IP addr: 0.0.0.0 mask: 255.255.255.255
> Dest IP addr: 0.0.0.0 mask: 255.255.255.255
> TOS: 0x0 mask: 0xff
> Src port: 0 mask: 0xffff
> Dest port: 4789 mask: 0x0
> VLAN EtherType: 0x0 mask: 0xffff
> VLAN: 0x0 mask: 0xffff
> User-defined: 0x0 mask: 0xffffffffffffffff
> Action: Direct to queue 0
> * >> Won't it show the VF queue numbers here?*
>
> 6. Start the VM over p2p1_0
> 7. Below is the Packet I am sending
> a) Dest MAC - VF Mac, Src MAC - any untagged, src ip - 1.1.1.1 dest ip -
> 2.2.2.2 src port - 100 dest port - 4789
> b) Dest MAC - VF Mac, Src MAC - any, untagged, src ip - 1.1.1.1 dest ip -
> 2.2.2.2 src port - 100 dest port - 4790
> c) Dest MAC - VF Mac, untagged, src ip - 1.1.1.1 dest ip - 2.2.2.2 src
> port - 100 dest port - 4791
>
> All the above testing is done on centOs-6.7 with ixgbe version - 4.3.13
> with patch you mentioned on 82599 Ethernet controller
> Linux XXX 2.6.32-573.22.1.el6.x86_64 #1 SMP Wed Mar 23 03:35:39 UTC 2016
> x86_64 x86_64 x86_64 GNU/Linux
>
>
> *Observation: *
> If the packet matches the rule, I am not able to see the packet in the VF,
> instead I am able to see the packet in PF.
> for the packets a) and b), I am able to see te packet only in PF. Even if
> the packet destination MAC is VF's MAC,
> I am able to see only in PF.
> If the packet is not matching the rule, then I am able to see the packet
> in VF, provided packet destination MAC is VF's MAC.
> *Question: *
> 1) Am I mapping the queues wrongly while adding the rules?
> 2) How to Identify which VF using which Queues?
>
> Request you to provide some help on it.
>
>
> On Tue, Mar 22, 2016 at 1:03 PM, bharath paulraj <bharathpaul@gmail.com>
> wrote:
>
>> Thanks a lot Michael. Finally i am able to see some light. I will try
>> the same in our setup and will post you the results.
>>
>> Thanks,
>> Bharath
>>
>> On Tue, Mar 22, 2016 at 12:09 PM, Qiu, Michael <michael.qiu@intel.com>
>> wrote:
>>
>>> Yes, we could let ovs using 82599 VF to do rx/tx. I don't know what's
>>> your l2 bridge, but since ovs could work I think your bridge also could
>>> work. But I only tested with one VF.
>>>
>>> Make sure below two patches (bifurcate driver) are included in your
>>> kernel:
>>>
>>> _https://patchwork.ozlabs.org/patch/476511/_
>>> _https://patchwork.ozlabs.org/patch/476516/_
>>>
>>> Mostly, if your kernel version in 4.2 or newer, it should be included.
>>>
>>> After you create VF, before you passthrough the VF to guest:
>>>
>>> (vf +1) << 32 + queue-index,
>>>
>>>
>>> 1. where vf is the VF index starting from 0
>>> 2. the queue-index is 0 if multi-queue support is not turned on, and
>>> this value is [0,1] if multiple-queue is turned on
>>>
>>>
>>> echo 1 > /sys/bus/pci/devices/0000\:05\:00.0/sriov_numvfs
>>> ifconfig $(PF_INTF) up
>>> ifconfig $(VF0_INFT) up
>>> ip link set $(PF_INTF) promisc on
>>> ethtool -K $(PF_INTF) ntuple on
>>> ethtool -N $(PF_INTF) flow-type udp4 dst-port 4789 action 0x100000000
>>> (VF0 queue 0)
>>>
>>> Here we using flow director to all let packets according to the rules to
>>> the VF, But I don't know if it could let the packets to other VFs at the
>>> same time.
>>>
>>> Thanks,
>>> Michael
>>>
>>> On 3/17/2016 2:43 PM, bharath paulraj wrote:
>>> > Hi Lu, Helin, Greg,
>>> >
>>> > Many thanks for your response, which is really quick. Now, If I want
>>> > to implement L2 bridging with Intel virtualization technologies, using
>>> > 82599 controller, then Michael is my only hope, as getting the new
>>> > kernel versions and upstream support will take considerable amount of
>>> > time.
>>> >
>>> > Michael, Could you please share your experience on L2 bridging
>>> > using Intel virtualization technologies.
>>> >
>>> > Thanks,
>>> > Bharath
>>> >
>>> > On Wed, Mar 16, 2016 at 9:40 PM, Rose, Gregory V
>>> > <gregory.v.rose@intel.com <mailto:gregory.v.rose@intel.com>> wrote:
>>> >
>>> > Intel has not supported promiscuous mode for virtual functions due
>>> > to the security concerns mentioned below.
>>> >
>>> > There will be upstream support in an upcoming Linux kernel for
>>> > setting virtual functions as "trusted" and when that is available
>>> > then Intel will allow virtual functions to enter unicast
>>> > promiscuous mode on those Ethernet controllers that support
>>> > promiscuous mode for virtual functions in the HW/FW. Be aware
>>> > that not all Intel Ethernet controllers have support for unicast
>>> > promiscuous mode for virtual functions. The only currently
>>> > released product that does is the X710/XL710.
>>> >
>>> > The key take away is that unicast promiscuous mode for X710/XL710
>>> > virtual functions requires Linux kernel support, iproute2 package
>>> > support and driver support. Only when all three of these are in
>>> > place will the feature work.
>>> >
>>> > Thanks,
>>> >
>>> > - Greg
>>> >
>>> > -----Original Message-----
>>> > From: Zhang, Helin
>>> > Sent: Wednesday, March 16, 2016 9:04 AM
>>> > To: bharath paulraj <bharathpaul@gmail.com
>>> > <mailto:bharathpaul@gmail.com>>; Lu, Wenzhuo <wenzhuo.lu@intel.com
>>> > <mailto:wenzhuo.lu@intel.com>>; Rowden, Aaron F
>>> > <aaron.f.rowden@intel.com <mailto:aaron.f.rowden@intel.com>>;
>>> > Rose, Gregory V <gregory.v.rose@intel.com
>>> > <mailto:gregory.v.rose@intel.com>>
>>> > Cc: dev@dpdk.org <mailto:dev@dpdk.org>; Qiu, Michael
>>> > <michael.qiu@intel.com <mailto:michael.qiu@intel.com>>; Jayakumar,
>>> > Muthurajan <muthurajan.jayakumar@intel.com
>>> > <mailto:muthurajan.jayakumar@intel.com>>
>>> > Subject: RE: [dpdk-dev] Reg: promiscuous mode on VF
>>> >
>>> > Hi Bharath
>>> >
>>> > For your question of "why intel does not support unicast
>>> > promiscuos mode?", I'd ask Aaron or Greg to give answers.
>>> > Thank you very much!
>>> >
>>> > Regards,
>>> > Helin
>>> >
>>> > > -----Original Message-----
>>> > > From: dev [mailto:dev-bounces@dpdk.org
>>> > <mailto:dev-bounces@dpdk.org>] On Behalf Of bharath paulraj
>>> > > Sent: Wednesday, March 16, 2016 11:29 PM
>>> > > To: Lu, Wenzhuo
>>> > > Cc: dev@dpdk.org <mailto:dev@dpdk.org>
>>> > > Subject: Re: [dpdk-dev] Reg: promiscuous mode on VF
>>> > >
>>> > > Hi Lu,
>>> > >
>>> > > Many thanks for your response. Again I have few more queries.
>>> > > If VF unicast promiscuous mode is not supported then can't we
>>> > > implement a Layer 2 bridging functionality using intel
>>> > virtualization
>>> > > technologies? Or Is there any other way, say tweeking some
>>> hardware
>>> > > registers or drivers, which may help us in implementing Layer 2
>>> > bridging.
>>> > > Also I would like to know, why intel does not support unicast
>>> > promiscuos mode?
>>> > > It could have been optional register settings and user should
>>> > have had
>>> > > a previleage to set or unset it. Besides, security reasons, is
>>> there
>>> > > any other big reason why Intel does not support this?
>>> > >
>>> > > Thanks,
>>> > > Bharath Paulraj
>>> > >
>>> > > On Wed, Mar 16, 2016 at 6:15 AM, Lu, Wenzhuo
>>> > <wenzhuo.lu@intel.com <mailto:wenzhuo.lu@intel.com>>
>>> > > wrote:
>>> > >
>>> > > > Hi Bharath,
>>> > > >
>>> > > > > 2) Is the above supported for 82599 controller? If it is
>>> > > > > supported
>>> > > > in the NIC,
>>> > > > > please provide the steps to enable.
>>> > > > Talking about 82599, VF unicast promiscuous mode is not
>>> supported.
>>> > > > Only broadcast and multicast can be supported.
>>> > > >
>>> > > > >
>>> > > > > Thanks,
>>> > > > > Bharath Paulraj
>>> > > >
>>> > >
>>> > >
>>> > >
>>> > > --
>>> > > Regards,
>>> > > Bharath
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > Regards,
>>> > Bharath
>>>
>>>
>>
>>
>> --
>> Regards,
>> Bharath
>>
>
>
>
> --
> Regards,
> Bharath
>
--
Regards,
Bharath
next prev parent reply other threads:[~2016-04-07 10:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-15 9:00 bharath paulraj
2016-03-16 0:45 ` Lu, Wenzhuo
2016-03-16 15:29 ` bharath paulraj
2016-03-16 15:54 ` Lu, Wenzhuo
2016-03-16 16:04 ` Zhang, Helin
2016-03-16 16:10 ` Rose, Gregory V
2016-03-17 6:42 ` bharath paulraj
2016-03-22 6:39 ` Qiu, Michael
2016-03-22 7:33 ` bharath paulraj
2016-03-31 10:43 ` bharath paulraj
2016-04-07 10:39 ` bharath paulraj [this message]
[not found] ` <C5551D9AAB213A418B7FD5E4A6F30A0789F7706A@ORSMSX116.amr.corp.intel.com>
2016-04-08 21:06 ` Rose, Gregory V
2016-04-12 5:51 ` bharath paulraj
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=CACfjA+nKJFUTHCKGA8HEch3JkRF7JMtXb-LvCkm9XYYuPXv2hw@mail.gmail.com \
--to=bharathpaul@gmail.com \
--cc=aaron.f.rowden@intel.com \
--cc=dev@dpdk.org \
--cc=gregory.v.rose@intel.com \
--cc=helin.zhang@intel.com \
--cc=michael.qiu@intel.com \
--cc=muthurajan.jayakumar@intel.com \
--cc=wenzhuo.lu@intel.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).