From: Shankar Krishnamurthy [mailto:shankar.krishnamur...@citrix.com]
Sent: Tuesday, September 15, 2015 11:00 PM
To: Rose, Gregory V; Shankar Krishnamurthy; e1000-devel@lists.sourceforge.net
Subject: RE: [E1000-devel] Vlan Table in I40e XL710
Thanks for response.
> Why? You're setting a VLAN filter with the tag value of 25. Why do
> promiscuous mode in addition?
--> I was confirming that I am _not_ setting p.VPE (essentially disabling VLAN
promiscuous ). We are in same page.
Still the packets are not going through.
To set and clear a VLAN filter should not require any call to the
i40e_aq_set_and_clr_vsi_vlan_promiscuous() function at all.
Use the MAC+VLAN filters.
- Greg
'set' is just the opcode name ' i40e_aqc_set_vsi_promiscuous_modes' - same is
used to 'clear' I guess.
The following code does this when 'set=0' is passed.
i40e_status i40e_aq_set_and_clr_vsi_vlan_promiscuous(struct i40e_hw *hw,
u16 seid, bool set, struct i40e_asq_cmd_details
*cmd_details)
{
struct i40e_aq_desc desc;
struct i40e_aqc_set_vsi_promiscuous_modes *cmd =
(struct i40e_aqc_set_vsi_promiscuous_modes *)&desc.params.raw;
i40e_status status;
u16 flags = 0;
i40e_fill_default_direct_cmd_desc(&desc,
i40e_aqc_opc_set_vsi_promiscuous_modes);
if (set)
flags |= I40E_AQC_SET_VSI_PROMISC_VLAN;
cmd->promiscuous_flags = CPU_TO_LE16(flags);
cmd->valid_flags = CPU_TO_LE16(I40E_AQC_SET_VSI_PROMISC_VLAN);
cmd->seid = CPU_TO_LE16(seid);
status = i40e_asq_send_command(hw, &desc, NULL, 0, cmd_details);
return status;
}
In the contrary, this is not the way to set p.VPE=0 (as described in L2
filtering algorithm) or someother/additional action needs to be taken, please
let me know
thanks,
Shankar.
-----Original Message-----
From: Rose, Gregory V [mailto:gregory.v.r...@intel.com]
Sent: Tuesday, September 15, 2015 3:43 PM
To: Shankar Krishnamurthy
<shankar.krishnamur...@citrix.com<mailto:shankar.krishnamur...@citrix.com>>;
e1000-devel@lists.sourceforge.net<mailto:e1000-devel@lists.sourceforge.net>
Subject: RE: [E1000-devel] Vlan Table in I40e XL710
> -----Original Message-----
> From: Shankar Krishnamurthy [mailto:shankar.krishnamur...@citrix.com]
> Sent: Tuesday, September 15, 2015 2:57 PM
> To:
> e1000-devel@lists.sourceforge.net<mailto:e1000-devel@lists.sourceforge.net>
> Subject: [E1000-devel] Vlan Table in I40e XL710
>
> Hi fortville Experts,
>
> Was trying to use VLAN Table (for filtering) in conjunction with
> MACVLAN table mentioned in "7.4.8.3 L2 Filtering Algorithm" (also cut
> n' pasted
> below)
>
> My test scenario:
> 1. In SRIOV mode, gave one VF to VM. For that, I added the
> corresponding MAC into MACVLAN table with vlan=25 2. Added VLAN table
> with vlan=25. (For p.VPE=0 I used
> 'i40e_aqc_opc_set_vsi_promiscuous_modes' opcode with vlan
> promiscuous.)
>
Why? You're setting a VLAN filter with the tag value of 25. Why do
promiscuous mode in addition?
> Now the packets are coming into this VM.
>
> 1. Now, I delete the vlan=25 entry in the VLAN table (expecting that
> packets stop coming in) 2. Packets are still coming in.
Turn off promiscuous mode.
- Greg
>
> But I am confused with this behavior. According the algorithm below,
> Namely:
> " EFilter = MFilter and (VFilter or p.VPE} and AddressType == Unicast;"
>
> The packets should have stopped coming in. What am I missing?
>
> Is there any global setting /register that I need to toggle for the
> VLAN table to be effective?
>
> Is VSI setup needs additional flags? Not sure
>
> thanks,
> Shankar.
>
> I40e Driver Version: 1.2.37
>
> 7.4.8.3 L2 Filtering Algorithm
> The following pseudo code describes the algorithm used to determine if
> a packet passes the L2 filtering element.
> // Global parameters
> // Define Lookup tables
> MacVlan Table: Array of {MAC (MAC Address), VLAN (VLAN tag)} Ethernet
> Controller XL710 - Internal Switch
> 728
> Mac Table: Array of {MAC (MAC Address)} VLAN table: Array of {VLAN
> (VLAN tag)} HashMacVlan Table: Array of {HashMAC (Hash Values), VLAN
> (VLAN tag), AddressType} HashMac Table: Array of {HashMAC (Hash
> Values) , AddressType} EtherType Table : Array of {Etype (Ethertypes
> Values)} MacEtherType Table: Array of {MAC (MAC Address), Etype
> (Ethertype value)} // Define Virtual ports modes Port.PUE //
> Promiscuous Unicast Enable Port.PME // Promiscuous Multicast Enable
> Port.BAM // Broadcast Enable Port.VPE // Promiscuous VLAN enable
> Port.MaxSize: Max Packet size
> L2_function(Packet)
> // Variables
> MFilter: = False // MAC Filtering
> VFilter: = False // VLAN Filtering
> EFilter: = False // Exclusive Filtering NEPMFilter = False // Non
> Exclusive Perfect MAC Filtering NEPFilter = False // Non Exclusive
> Perfect Filtering NEIPMFilter = False // Non Exclusive Imperfect MAC
> Filtering NEIPFilter = False // Non Exclusive Imperfect Filtering Pass
> = False // Final decision.
> //Define packet parameters
> DA = Packet.DA //Destination Address of the packet VID = Packet.VLAN
> ID // Vlan tag of the packet Etype = Packet.Ethertype // Ethertype of
> the packet AddressType //Type of address of the DA. Can be Unicast,
> Multicast or Broadcast.
> HDA = HashFunction(DA).
> PSize: Packet size. This do not include any tag or other header
> removed by previous stages or to be added by following stages.
>
> // Exclusive Filters
> For Each entry e in MacVlan Table
> If (DA == e.MAC and (VID == e.VLAN or (VID == NULL and e.VLAN == 0))
> MFilter = True; For Each entry e in Mac Table If (DA == e.MAC) MFilter
> = True; For Each entry e in Ethertype Table If (Etype == e.Etype)
> MFilter = True; For Each entry e in MacEthertype Table If (DA == e.MAC
> and Etype == e.Etype) MFilter = True; For Each entry e in Vlan Table
> If (VID == e.VLAN or (VID == NULL and e.VLAN == 0)) VFilter = True; //
> VLAN filters are ANDed with the previous filters unless promiscuous
> VLAN is enabled EFilter = MFilter and (VFilter or p.VPE} and
> AddressType == Unicast; // Non Exclusive Perfect Filters If
> (AddressType == Unicast and p.PUE == 1) NEPMFilter = True; If
> (AddressType == Multicast and (p.PME == 1 or MFilter)) NEPMFilter =
> True; If (AddressType == Broadcast and (p.BAM == 1 or MFilter))
> NEPMFilter = True; // VLAN filters are ANDed with the previous filters
> unless promiscuous VLAN is enabled NEPFilter = NEPMFilter and (VFilter
> or p.VPE}; // Non Exclusive Imperfect Filters For Each entry e in
> HashMACVlan Table If (HDA == e.HashMAC and (VID == e.VLAN or (VID ==
> NULL and e.VLAN == 0)) and AddressType == e.AddressType) NEIPMFilter =
> True; For Each entry e in HashMAC Table If (HDA == e.HashMAC and
> AddressType == e.AddressType) NEIPMFilter = True; // VLAN filters are
> ANDed with the previous filters unless promiscuous VLAN is enabled
> NIEPFilter = NIEPMFilter and (VFilter or p.VPE}; // Packet size
> filtering is done at the queue level, so it is not part of the switch
> algorithm Pass = (EFilter or NEPFilter or NEIPFilter) Return Pass; }
>
> -----Original Message-----
> From: Ronciak, John [mailto:john.ronc...@intel.com]
> Sent: Tuesday, September 15, 2015 10:40 AM
> To: Fujinaka, Todd <todd.fujin...@intel.com<mailto:todd.fujin...@intel.com>>;
> zheloba...@prosoftsystems.ru<mailto:zheloba...@prosoftsystems.ru>;
> e1000-devel@lists.sourceforge.net<mailto:e1000-devel@lists.sourceforge.net>
> Subject: Re: [E1000-devel] Intel 82551IL chips
>
> As long as there is no copy and pasting from the Linux driver to the
> QNX driver it should not be a problem. I'm not a lawyer but that's
> generally the case. That said, since the driver works after another a
> second reboot it's probably not related to the driver. This is
> probably something that is related to the system during the PCI
> enumeration of devices. Are all the other devices seen on a cold boot? Is
> there an equivalent to 'lspci'
> in QNX? If so what's it show on the first boot from power-off? Are
> all the devices seen at that point or are some missing?
>
> Cheers,
> John
>
> > -----Original Message-----
> > From: Fujinaka, Todd [mailto:todd.fujin...@intel.com]
> > Sent: Tuesday, September 15, 2015 9:43 AM
> > To:
> > zheloba...@prosoftsystems.ru<mailto:zheloba...@prosoftsystems.ru<mailto:zheloba...@prosoftsystems.ru%3cmailto:zheloba...@prosoftsystems.ru>>;
> e1000-devel@lists.sourceforge.net<mailto:e1000-<mailto:e1000-devel@lists.sourceforge.net%3cmailto:e1000->
> de...@lists.sourceforge.net<mailto:de...@lists.sourceforge.net>>
> > Subject: Re: [E1000-devel] Intel 82551IL chips
> >
> > The 82551L has been EOLed for about nine years by my estimation. We
> > don't have any further support for it.
> >
> > Also, it is probably a violation of the GPL to start with the Linux
> > driver to work on the QNX driver. I would suggest trying the FreeBSD
> driver.
> >
> > Todd Fujinaka
> > Software Application Engineer
> > Networking Division (ND)
> > Intel Corporation
> > todd.fujin...@intel.com<mailto:todd.fujin...@intel.com<mailto:todd.fujin...@intel.com%3cmailto:todd.fujin...@intel.com>>
> > (503) 712-4565
> >
> > -----Original Message-----
> > From: Желобанов Дмитрий Владимирович
> > [mailto:zheloba...@prosoftsystems.ru]
> > Sent: Tuesday, September 15, 2015 5:15 AM
> > To:
> > e1000-devel@lists.sourceforge.net<mailto:e1000-<mailto:e1000-devel@lists.sourceforge.net%3cmailto:e1000->
> de...@lists.sourceforge.net<mailto:de...@lists.sourceforge.net>>
> > Subject: [E1000-devel] Intel 82551IL chips
> >
> > Hello,
> >
> > We use chips 82551IL (did 0x1209 rev 0x10) in our embedded platforms.
> > Our devices run QNX operation system. We faced with an issue:
> > sometimes our devices don't receive Ethernet packets right after
> > boot at all, only reboot helps to revive the devices. We think the
> > root problem is in hardware- software communication with the
> > Ethernet controller, or rather in QNX Ethernet driver.
> > I looked in Linux driver (e100.c) and found, the driver uploads
> > special firmware in chips like ours.
> >
> > So, could you give us a document which clarifies changes in
> > d102e_ucode.bin firmware from the original on chip microcode?
> >
> > Желобанов Д.В.
> > ООО <Прософт-Системы>, г. Екатеринбург.
> >
> >
> > --------------------------------------------------------------------
> > --
> > -------- _______________________________________________
> > E1000-devel mailing list
> > E1000-devel@lists.sourceforge.net<mailto:E1000-<mailto:E1000-devel@lists.sourceforge.net%3cmailto:E1000->
> de...@lists.sourceforge.net<mailto:de...@lists.sourceforge.net>>
> > https://lists.sourceforge.net/lists/listinfo/e1000-devel
> > To learn more about Intel® Ethernet, visit
> > http://communities.intel.com/community/wired
>
> ----------------------------------------------------------------------
> ----
> ----
> _______________________________________________
> E1000-devel mailing list
> E1000-devel@lists.sourceforge.net<mailto:E1000-<mailto:E1000-devel@lists.sourceforge.net%3cmailto:E1000->
> de...@lists.sourceforge.net<mailto:de...@lists.sourceforge.net>>
> https://lists.sourceforge.net/lists/listinfo/e1000-devel
> To learn more about Intel® Ethernet, visit
> http://communities.intel.com/community/wired
------------------------------------------------------------------------------
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit
http://communities.intel.com/community/wired
