* question about eth and vlan item in flow pattern @ 2024-04-10 11:37 Jie Hai 2024-04-10 12:33 ` Thomas Monjalon 2024-04-10 13:19 ` Ivan Malov 0 siblings, 2 replies; 8+ messages in thread From: Jie Hai @ 2024-04-10 11:37 UTC (permalink / raw) To: Yuying Zhang, Aman Singh, Thomas Monjalon, ferruh.yigit@amd.com >> Ferruh Yigit, andrew.rybchenko, ivan.malov, dekelp, psatheesh, adrien.mazarguil, fengchengwen, Huisong Li, Dengdui Huang Cc: dev Hi, all, I have some questions about the sub-options for ``VLAN`` and ``ETH`` item. According to the documentation, ``has_vlan`` is sub-option of ``ETH`` item and it means that the pattern contains at least one vlan. The ``VLAN`` item is used to match tagged packets and have some sub-options such as ``vid``, ``tci``, etc. If we combine them, what should the effect be? For instance, rule-0: flow create 0 ingress pattern eth has_vlan is 1 / vlan / end actions queue index 2 / end rule-1: flow create 0 ingress pattern eth has_vlan is 1 / vlan vid is 10 / end actions queue index 2 / end For rule-0, should it match single-tagged packets only or multi-tagged only or both? That is to say, which one will take effect, `has_vlan is 1` or `vlan` or both? For rule-2, which packets should it match, with inner VLAN id 10, or outer VLAN id 10, or both 10? The hns3 driver supports only the exact matching of VLAN numer. And it is planned to adapt ``has_vlan`` and ``has_more_vlan`` to the meaning of one VLAN for hns3 driver. Therefore, if the preceding combinations are supported, we need to confirm the exact meanings. So, what are your views on the above question? ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: question about eth and vlan item in flow pattern 2024-04-10 11:37 question about eth and vlan item in flow pattern Jie Hai @ 2024-04-10 12:33 ` Thomas Monjalon 2024-04-10 13:19 ` Ivan Malov 1 sibling, 0 replies; 8+ messages in thread From: Thomas Monjalon @ 2024-04-10 12:33 UTC (permalink / raw) To: Yuying Zhang, Aman Singh, Ferruh Yigit, andrew.rybchenko, ivan.malov, dekelp, psatheesh, adrien.mazarguil, fengchengwen, Huisong Li, Dengdui Huang, Jie Hai Cc: dev, orika, Dariusz Sosnowski Hello, 10/04/2024 13:37, Jie Hai: > Hi, all, > > I have some questions about the sub-options for ``VLAN`` and ``ETH`` item. If it is not clear in the doxygen documentation, please do not hesitate to submit a patch to make it more explicit. > According to the documentation, ``has_vlan`` is sub-option of ``ETH`` > item and it means that the pattern contains at least one vlan. Yes > The ``VLAN`` item is used to match tagged packets and have some > sub-options such as ``vid``, ``tci``, etc. > > If we combine them, what should the effect be? > For instance, > > rule-0: flow create 0 ingress pattern eth has_vlan is 1 / vlan / end > actions queue index 2 / end I don't think the item "vlan" has any impact here. I mean it is redundant with "has_vlan". > rule-1: flow create 0 ingress pattern eth has_vlan is 1 / vlan vid is > 10 / end actions queue index 2 / end > > For rule-0, should it match single-tagged packets only or multi-tagged > only or both? I would say it matches 1 VLAN or more. > That is to say, which one will take effect, `has_vlan is 1` or `vlan` > or both? I think it is redundant. The real interesting usage of "has_vlan" would be for matching untagged packets. > For rule-2, which packets should it match, with inner VLAN id 10, or You mean rule-1 > outer VLAN id 10, or both 10? In case of QinQ, I suppose specifying only 1 VLAN allows to match either inner or outer. > The hns3 driver supports only the exact matching of VLAN numer. > And it is planned to adapt ``has_vlan`` and ``has_more_vlan`` to the > meaning of one VLAN for hns3 driver. Therefore, if the preceding > combinations are supported, we need to confirm the exact meanings. > > So, what are your views on the above question? I'm adding Ori Kam, maintainer of rte_flow API to confirm. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: question about eth and vlan item in flow pattern 2024-04-10 11:37 question about eth and vlan item in flow pattern Jie Hai 2024-04-10 12:33 ` Thomas Monjalon @ 2024-04-10 13:19 ` Ivan Malov 2024-04-23 9:34 ` Jie Hai 1 sibling, 1 reply; 8+ messages in thread From: Ivan Malov @ 2024-04-10 13:19 UTC (permalink / raw) To: Jie Hai Cc: Yuying Zhang, Aman Singh, Thomas Monjalon, ferruh.yigit@amd.com >> Ferruh Yigit, andrew.rybchenko, dekelp, psatheesh, adrien.mazarguil, fengchengwen, Huisong Li, Dengdui Huang, dev Hi Jie, Consider the following examples: 1) flow create 0 ingress pattern eth / ipv4 proto is 17 / udp / end \ actions queue index 1 / end 2) flow create 0 ingress pattern eth / ipv4 / udp / end \ actions queue index 1 / end Generally speaking, these two rules might be equivalent, with "proto is 17" in the first one probably being redundant (the very presence of "udp" item might stand for the same match criterion -- the protocol ID being 17). And I'd be tempted to treat the "has_vlan" case similarly. Consider: 3) flow create 0 ingress pattern eth has_vlan is 1 / vlan / end \ actions queue index 1 / end 4) flow create 0 ingress pattern eth / vlan / end \ actions queue index 1 / end (rule (3) is similar to "rule-0" from your example) Rules (3) and (4) seem equivalent to me -- the "has_vlan is 1" bit might be redundant in flow (3) -- the presence of item "vlan" sort of means the same. Rule (3) and (4) should probably match both single-tagged and double-tagged packets because, in both cases, the pattern does not clarify which protocol follows the outermost VLAN tag. If one needs to exclude double-tag match, they should clarify the rule in one of the possible ways, in example: - pattern eth / vlan has_more_vlan is 0 / end - pattern eth / vlan tpid is 0x0800 / end - pattern eth / vlan / ipv4 / end (the "tpid" goes to the "hdr.eth_proto" of "struct rte_flow_item_vlan"). With regard to the question about VLAN ID match, "pattern eth / vlan vid is 10", as well as "pattern eth has_vlan is 1 / vlan vid is 10", should probably match only on the outermost tag ID, -- that is, not on the inner one and not on both. That is because the "vid is 10" criterion relates to the specific header, as per the match item it sits in. If the user wants to match on the inner VLAN ID (say, 11), they should clarify specify it as follows: - pattern eth / vlan vid is 10 / vlan vid is 11 / end - pattern eth / vlan / vlan vid is 11 / end Hopefully, the rest of DPDK vendor community can correct me in case I got that wrong. Should you have more questions, please feel free to ask such. Thank you. On Wed, 10 Apr 2024, Jie Hai wrote: > Hi, all, > > I have some questions about the sub-options for ``VLAN`` and ``ETH`` item. > > According to the documentation, ``has_vlan`` is sub-option of ``ETH`` > item and it means that the pattern contains at least one vlan. > The ``VLAN`` item is used to match tagged packets and have some > sub-options such as ``vid``, ``tci``, etc. > > If we combine them, what should the effect be? > For instance, > > rule-0: flow create 0 ingress pattern eth has_vlan is 1 / vlan / end > actions queue index 2 / end > rule-1: flow create 0 ingress pattern eth has_vlan is 1 / vlan vid is 10 / > end actions queue index 2 / end > > For rule-0, should it match single-tagged packets only or multi-tagged only > or both? > That is to say, which one will take effect, `has_vlan is 1` or `vlan` or > both? > > For rule-2, which packets should it match, with inner VLAN id 10, or outer > VLAN id 10, or both 10? > > The hns3 driver supports only the exact matching of VLAN numer. > And it is planned to adapt ``has_vlan`` and ``has_more_vlan`` to the > meaning of one VLAN for hns3 driver. Therefore, if the preceding combinations > are supported, we need to confirm the exact meanings. > > So, what are your views on the above question? > > > > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: question about eth and vlan item in flow pattern 2024-04-10 13:19 ` Ivan Malov @ 2024-04-23 9:34 ` Jie Hai 2024-04-23 11:44 ` Ivan Malov 0 siblings, 1 reply; 8+ messages in thread From: Jie Hai @ 2024-04-23 9:34 UTC (permalink / raw) To: Ivan Malov Cc: Yuying Zhang, Aman Singh, Thomas Monjalon, ferruh.yigit@amd.com >> Ferruh Yigit, andrew.rybchenko, dekelp, psatheesh, adrien.mazarguil, fengchengwen, Huisong Li, Dengdui Huang, dev, Ori Kam Hi, Ivan Malov, Sorry for the late reply. On 2024/4/10 21:19, Ivan Malov wrote: > Hi Jie, > > Consider the following examples: > 1) flow create 0 ingress pattern eth / ipv4 proto is 17 / udp / end \ > actions queue index 1 / end > 2) flow create 0 ingress pattern eth / ipv4 / udp / end \ > actions queue index 1 / end > > Generally speaking, these two rules might be equivalent, with "proto is > 17" in > the first one probably being redundant (the very presence of "udp" item > might > stand for the same match criterion -- the protocol ID being 17). I can understand that. > > And I'd be tempted to treat the "has_vlan" case similarly. Consider: > 3) flow create 0 ingress pattern eth has_vlan is 1 / vlan / end \ > actions queue index 1 / end > 4) flow create 0 ingress pattern eth / vlan / end \ > actions queue index 1 / end > > (rule (3) is similar to "rule-0" from your example) > > Rules (3) and (4) seem equivalent to me -- the "has_vlan is 1" bit might be > redundant in flow (3) -- the presence of item "vlan" sort of means the > same. > Rule (3) and (4) should probably match both single-tagged and double-tagged > packets because, in both cases, the pattern does not clarify which protocol > follows the outermost VLAN tag. If one needs to exclude double-tag match, > they should clarify the rule in one of the possible ways, in example: > > - pattern eth / vlan has_more_vlan is 0 / end > - pattern eth / vlan tpid is 0x0800 / end > - pattern eth / vlan / ipv4 / end > > (the "tpid" goes to the "hdr.eth_proto" of "struct rte_flow_item_vlan"). > As mentioned above, `has_vlan is 1` and `vlan` are the same, which means `vlan` stands for any-tagged vlan, Then, is the introduction of `has_vlan` and `has_more_vlan` unnecessary? There are drivers seeing `vlan` an one vlan layer and match 'eth/vlan/end' with single-tagged packets, e.g.bnxt, hns3, etc. I think this meaning makes it easier to distinguish the functions of the two. The `has_more_vlan is 1` is defined and used by some drivers, like mlx5. While the `has_more_vlan is 0` is not defined. Here you give the meaning as `having no vlan after this vlan`. Then, What should the follow rule mean? single-tagged or double tagged? - pattern eth / vlan tpid is 0x8100 has_more_vlan is 0 / end > With regard to the question about VLAN ID match, "pattern eth / vlan vid > is 10", > as well as "pattern eth has_vlan is 1 / vlan vid is 10", should probably > match > only on the outermost tag ID, -- that is, not on the inner one and not > on both. I agree with it. > That is because the "vid is 10" criterion relates to the specific header, > as per the match item it sits in. If the user wants to match on the > inner VLAN ID (say, 11), they should clarify specify it as follows: > > - pattern eth / vlan vid is 10 / vlan vid is 11 / end > - pattern eth / vlan / vlan vid is 11 / end > > Hopefully, the rest of DPDK vendor community can correct me in case I got > that wrong. Should you have more questions, please feel free to ask such. > > Thank you. > > On Wed, 10 Apr 2024, Jie Hai wrote: > >> Hi, all, >> >> I have some questions about the sub-options for ``VLAN`` and ``ETH`` >> item. >> >> According to the documentation, ``has_vlan`` is sub-option of ``ETH`` >> item and it means that the pattern contains at least one vlan. >> The ``VLAN`` item is used to match tagged packets and have some >> sub-options such as ``vid``, ``tci``, etc. >> >> If we combine them, what should the effect be? >> For instance, >> >> rule-0: flow create 0 ingress pattern eth has_vlan is 1 / vlan / >> end actions queue index 2 / end >> rule-1: flow create 0 ingress pattern eth has_vlan is 1 / vlan vid >> is 10 / end actions queue index 2 / end >> >> For rule-0, should it match single-tagged packets only or multi-tagged >> only or both? >> That is to say, which one will take effect, `has_vlan is 1` or `vlan` >> or both? >> >> For rule-2, which packets should it match, with inner VLAN id 10, or >> outer VLAN id 10, or both 10? >> >> The hns3 driver supports only the exact matching of VLAN numer. >> And it is planned to adapt ``has_vlan`` and ``has_more_vlan`` to the >> meaning of one VLAN for hns3 driver. Therefore, if the preceding >> combinations are supported, we need to confirm the exact meanings. >> >> So, what are your views on the above question? >> >> >> >> > . ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: question about eth and vlan item in flow pattern 2024-04-23 9:34 ` Jie Hai @ 2024-04-23 11:44 ` Ivan Malov 2024-04-24 20:21 ` Dariusz Sosnowski 0 siblings, 1 reply; 8+ messages in thread From: Ivan Malov @ 2024-04-23 11:44 UTC (permalink / raw) To: Jie Hai Cc: Yuying Zhang, Aman Singh, Thomas Monjalon, ferruh.yigit@amd.com >> Ferruh Yigit, andrew.rybchenko, dekelp, psatheesh, adrien.mazarguil, fengchengwen, Huisong Li, Dengdui Huang, dev, Ori Kam [-- Attachment #1: Type: text/plain, Size: 5292 bytes --] Hi, Please see below. On Tue, 23 Apr 2024, Jie Hai wrote: > Hi, Ivan Malov, > Sorry for the late reply. > On 2024/4/10 21:19, Ivan Malov wrote: >> Hi Jie, >> >> Consider the following examples: >> 1) flow create 0 ingress pattern eth / ipv4 proto is 17 / udp / end \ >> actions queue index 1 / end >> 2) flow create 0 ingress pattern eth / ipv4 / udp / end \ >> actions queue index 1 / end >> >> Generally speaking, these two rules might be equivalent, with "proto is 17" >> in >> the first one probably being redundant (the very presence of "udp" item >> might >> stand for the same match criterion -- the protocol ID being 17). > I can understand that. Very well. >> >> And I'd be tempted to treat the "has_vlan" case similarly. Consider: >> 3) flow create 0 ingress pattern eth has_vlan is 1 / vlan / end \ >> actions queue index 1 / end >> 4) flow create 0 ingress pattern eth / vlan / end \ >> actions queue index 1 / end >> >> (rule (3) is similar to "rule-0" from your example) >> >> Rules (3) and (4) seem equivalent to me -- the "has_vlan is 1" bit might be >> redundant in flow (3) -- the presence of item "vlan" sort of means the >> same. > >> Rule (3) and (4) should probably match both single-tagged and double-tagged >> packets because, in both cases, the pattern does not clarify which protocol >> follows the outermost VLAN tag. If one needs to exclude double-tag match, >> they should clarify the rule in one of the possible ways, in example: >> >> - pattern eth / vlan has_more_vlan is 0 / end >> - pattern eth / vlan tpid is 0x0800 / end >> - pattern eth / vlan / ipv4 / end >> >> (the "tpid" goes to the "hdr.eth_proto" of "struct rte_flow_item_vlan"). >> > As mentioned above, `has_vlan is 1` and `vlan` are the same, > which means `vlan` stands for any-tagged vlan, > Then, is the introduction of `has_vlan` and `has_more_vlan` unnecessary? It's not clear why you believe it's unnecessary. Some vendors support boolean match on "is outer VLAN present" and "is inner VLAN present" in addition to exact match on TPID/TCI. It may be convenient to expose these match criteria as sub-fields in ETH and VLAN items. This should allow for faster parsing as one can drop item VLAN from pattern in case there's no intention to match on TPID/TCI. > > There are drivers seeing `vlan` an one vlan layer and match 'eth/vlan/end' > with single-tagged packets, e.g.bnxt, hns3, etc. > I think this meaning makes it easier to distinguish the functions of the two. > > The `has_more_vlan is 1` is defined and used by some drivers, like mlx5. > While the `has_more_vlan is 0` is not defined. What do you mean by saying "not defined"? Not defined where? Having "has_more_vlan is 0" is perfectly legit, isn't it? > Here you give the meaning as `having no vlan after this vlan`. > Then, What should the follow rule mean? single-tagged or double tagged? > > - pattern eth / vlan tpid is 0x8100 has_more_vlan is 0 / end Item VLAN here is supposed to describe the header _immediately_ following the ETH one, isn't it? If so, the rule means single-tagged. Doesn't it? Thank you. > >> With regard to the question about VLAN ID match, "pattern eth / vlan vid is >> 10", >> as well as "pattern eth has_vlan is 1 / vlan vid is 10", should probably >> match >> only on the outermost tag ID, -- that is, not on the inner one and not on >> both. > I agree with it. >> That is because the "vid is 10" criterion relates to the specific header, >> as per the match item it sits in. If the user wants to match on the >> inner VLAN ID (say, 11), they should clarify specify it as follows: >> >> - pattern eth / vlan vid is 10 / vlan vid is 11 / end >> - pattern eth / vlan / vlan vid is 11 / end >> > >> Hopefully, the rest of DPDK vendor community can correct me in case I got >> that wrong. Should you have more questions, please feel free to ask such. >> >> Thank you. >> >> On Wed, 10 Apr 2024, Jie Hai wrote: >> >>> Hi, all, >>> >>> I have some questions about the sub-options for ``VLAN`` and ``ETH`` item. >>> >>> According to the documentation, ``has_vlan`` is sub-option of ``ETH`` >>> item and it means that the pattern contains at least one vlan. >>> The ``VLAN`` item is used to match tagged packets and have some >>> sub-options such as ``vid``, ``tci``, etc. >>> >>> If we combine them, what should the effect be? >>> For instance, >>> >>> rule-0: flow create 0 ingress pattern eth has_vlan is 1 / vlan / end >>> actions queue index 2 / end >>> rule-1: flow create 0 ingress pattern eth has_vlan is 1 / vlan vid is 10 >>> / end actions queue index 2 / end >>> >>> For rule-0, should it match single-tagged packets only or multi-tagged >>> only or both? >>> That is to say, which one will take effect, `has_vlan is 1` or `vlan` or >>> both? >>> >>> For rule-2, which packets should it match, with inner VLAN id 10, or outer >>> VLAN id 10, or both 10? >>> >>> The hns3 driver supports only the exact matching of VLAN numer. >>> And it is planned to adapt ``has_vlan`` and ``has_more_vlan`` to the >>> meaning of one VLAN for hns3 driver. Therefore, if the preceding >>> combinations are supported, we need to confirm the exact meanings. >>> >>> So, what are your views on the above question? >>> >>> >>> >>> >> . > ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: question about eth and vlan item in flow pattern 2024-04-23 11:44 ` Ivan Malov @ 2024-04-24 20:21 ` Dariusz Sosnowski 2024-04-24 21:46 ` Ivan Malov 0 siblings, 1 reply; 8+ messages in thread From: Dariusz Sosnowski @ 2024-04-24 20:21 UTC (permalink / raw) To: Ivan Malov, Jie Hai Cc: Yuying Zhang, Aman Singh, NBU-Contact-Thomas Monjalon (EXTERNAL), ferruh.yigit@amd.com >> Ferruh Yigit, andrew.rybchenko, dekelp, psatheesh, NBU-Contact-Adrien Mazarguil (EXTERNAL), fengchengwen, Huisong Li, Dengdui Huang, dev, Ori Kam > -----Original Message----- > From: Ivan Malov <ivan.malov@arknetworks.am> > Sent: Tuesday, April 23, 2024 13:44 > To: Jie Hai <haijie1@huawei.com> > Cc: Yuying Zhang <yuying.zhang@intel.com>; Aman Singh > <aman.deep.singh@intel.com>; NBU-Contact-Thomas Monjalon (EXTERNAL) > <thomas@monjalon.net>; ferruh.yigit@amd.com >> Ferruh Yigit > <ferruh.yigit@amd.com>; andrew.rybchenko@oktetlabs.ru; > dekelp@nvidia.com; psatheesh@marvell.com; NBU-Contact-Adrien Mazarguil > (EXTERNAL) <adrien.mazarguil@6wind.com>; fengchengwen > <fengchengwen@huawei.com>; Huisong Li <lihuisong@huawei.com>; > Dengdui Huang <huangdengdui@huawei.com>; dev@dpdk.org; Ori Kam > <orika@nvidia.com> > Subject: Re: question about eth and vlan item in flow pattern > > Hi, > > Please see below. > > On Tue, 23 Apr 2024, Jie Hai wrote: > > > Hi, Ivan Malov, > > Sorry for the late reply. > > On 2024/4/10 21:19, Ivan Malov wrote: > >> Hi Jie, > >> > >> Consider the following examples: > >> 1) flow create 0 ingress pattern eth / ipv4 proto is 17 / udp / end \ > >> actions queue index 1 / end > >> 2) flow create 0 ingress pattern eth / ipv4 / udp / end \ > >> actions queue index 1 / end > >> > >> Generally speaking, these two rules might be equivalent, with "proto is 17" > >> in > >> the first one probably being redundant (the very presence of "udp" > >> item might stand for the same match criterion -- the protocol ID > >> being 17). > > I can understand that. > Very well. > > >> > >> And I'd be tempted to treat the "has_vlan" case similarly. Consider: > >> 3) flow create 0 ingress pattern eth has_vlan is 1 / vlan / end \ > >> actions queue index 1 / end > >> 4) flow create 0 ingress pattern eth / vlan / end \ > >> actions queue index 1 / end > >> > >> (rule (3) is similar to "rule-0" from your example) > >> > >> Rules (3) and (4) seem equivalent to me -- the "has_vlan is 1" bit > >> might be redundant in flow (3) -- the presence of item "vlan" sort of > >> means the same. > > > >> Rule (3) and (4) should probably match both single-tagged and > >> double-tagged packets because, in both cases, the pattern does not > >> clarify which protocol follows the outermost VLAN tag. If one needs > >> to exclude double-tag match, they should clarify the rule in one of the > possible ways, in example: > >> > >> - pattern eth / vlan has_more_vlan is 0 / end > >> - pattern eth / vlan tpid is 0x0800 / end > >> - pattern eth / vlan / ipv4 / end > >> > >> (the "tpid" goes to the "hdr.eth_proto" of "struct rte_flow_item_vlan"). > >> > > As mentioned above, `has_vlan is 1` and `vlan` are the same, which > > means `vlan` stands for any-tagged vlan, Then, is the introduction of > > `has_vlan` and `has_more_vlan` unnecessary? > It's not clear why you believe it's unnecessary. Some vendors support boolean > match on "is outer VLAN present" and "is inner VLAN present" > in addition to exact match on TPID/TCI. It may be convenient to expose these > match criteria as sub-fields in ETH and VLAN items. > This should allow for faster parsing as one can drop item VLAN from pattern in > case there's no intention to match on TPID/TCI. To expand the argument on convenience by providing an example, `has_vlan` allows to construct a following logic: 1) flow create 0 group X ingress pattern eth has_vlan is 1 / end actions jump group Y / end 2) flow create 0 group X ingress pattern eth has_vlan is 0 / end actions jump group Z / end 3) flow create 0 group Y ingress pattern eth / vlan vid is N / end actions /* actions for tagged traffic */ 4) flow create 0 group Z ingress pattern eth / end actions /* actions for non-tagged traffic */ Traffic can be split between different groups - one group for tagged and another for non-tagged packets. `has_vlan` gives more flexibility in the API. > > > > There are drivers seeing `vlan` an one vlan layer and match 'eth/vlan/end' > > with single-tagged packets, e.g.bnxt, hns3, etc. > > I think this meaning makes it easier to distinguish the functions of the two. > > > > The `has_more_vlan is 1` is defined and used by some drivers, like mlx5. > > While the `has_more_vlan is 0` is not defined. > What do you mean by saying "not defined"? Not defined where? > Having "has_more_vlan is 0" is perfectly legit, isn't it? > > > Here you give the meaning as `having no vlan after this vlan`. > > Then, What should the follow rule mean? single-tagged or double tagged? > > > > - pattern eth / vlan tpid is 0x8100 has_more_vlan is 0 / end > Item VLAN here is supposed to describe the header _immediately_ following > the ETH one, isn't it? If so, the rule means single-tagged. Doesn't it? I also think this rule means single-tagged, but on the other hand I think it's also ill-defined. tpid field in VLAN item defines the inner packet type, so this pattern should match the following packet: dmac=<any> smac=<any> ether_type=0x8100 // match single-tagged packet pcp=<any> vid=<any> ether_type=0x8100 // from tpid VLAN item Which is an incorrect packet. > Thank you. > > > > >> With regard to the question about VLAN ID match, "pattern eth / vlan > >> vid is 10", as well as "pattern eth has_vlan is 1 / vlan vid is 10", > >> should probably match only on the outermost tag ID, -- that is, not > >> on the inner one and not on both. > > I agree with it. > >> That is because the "vid is 10" criterion relates to the specific > >> header, as per the match item it sits in. If the user wants to match > >> on the inner VLAN ID (say, 11), they should clarify specify it as follows: > >> > >> - pattern eth / vlan vid is 10 / vlan vid is 11 / end > >> - pattern eth / vlan / vlan vid is 11 / end > >> > > > >> Hopefully, the rest of DPDK vendor community can correct me in case I > >> got that wrong. Should you have more questions, please feel free to ask > such. > >> > >> Thank you. > >> > >> On Wed, 10 Apr 2024, Jie Hai wrote: > >> > >>> Hi, all, > >>> > >>> I have some questions about the sub-options for ``VLAN`` and ``ETH`` > item. > >>> > >>> According to the documentation, ``has_vlan`` is sub-option of > >>> ``ETH`` item and it means that the pattern contains at least one vlan. > >>> The ``VLAN`` item is used to match tagged packets and have some > >>> sub-options such as ``vid``, ``tci``, etc. > >>> > >>> If we combine them, what should the effect be? > >>> For instance, > >>> > >>> rule-0: flow create 0 ingress pattern eth has_vlan is 1 / vlan / > >>> end actions queue index 2 / end > >>> rule-1: flow create 0 ingress pattern eth has_vlan is 1 / vlan vid > >>> is 10 / end actions queue index 2 / end > >>> > >>> For rule-0, should it match single-tagged packets only or > >>> multi-tagged only or both? > >>> That is to say, which one will take effect, `has_vlan is 1` or > >>> `vlan` or both? > >>> > >>> For rule-2, which packets should it match, with inner VLAN id 10, or > >>> outer VLAN id 10, or both 10? > >>> > >>> The hns3 driver supports only the exact matching of VLAN numer. > >>> And it is planned to adapt ``has_vlan`` and ``has_more_vlan`` to the > >>> meaning of one VLAN for hns3 driver. Therefore, if the preceding > >>> combinations are supported, we need to confirm the exact meanings. > >>> > >>> So, what are your views on the above question? > >>> > >>> > >>> > >>> > >> . > > ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: question about eth and vlan item in flow pattern 2024-04-24 20:21 ` Dariusz Sosnowski @ 2024-04-24 21:46 ` Ivan Malov 2024-05-13 1:45 ` Jie Hai 0 siblings, 1 reply; 8+ messages in thread From: Ivan Malov @ 2024-04-24 21:46 UTC (permalink / raw) To: Dariusz Sosnowski Cc: Jie Hai, Yuying Zhang, Aman Singh, NBU-Contact-Thomas Monjalon (EXTERNAL), ferruh.yigit@amd.com >> Ferruh Yigit, andrew.rybchenko, dekelp, psatheesh, NBU-Contact-Adrien Mazarguil (EXTERNAL), fengchengwen, Huisong Li, Dengdui Huang, dev, Ori Kam [-- Attachment #1: Type: text/plain, Size: 7840 bytes --] Hi, On Wed, 24 Apr 2024, Dariusz Sosnowski wrote: >> -----Original Message----- >> From: Ivan Malov <ivan.malov@arknetworks.am> >> Sent: Tuesday, April 23, 2024 13:44 >> To: Jie Hai <haijie1@huawei.com> >> Cc: Yuying Zhang <yuying.zhang@intel.com>; Aman Singh >> <aman.deep.singh@intel.com>; NBU-Contact-Thomas Monjalon (EXTERNAL) >> <thomas@monjalon.net>; ferruh.yigit@amd.com >> Ferruh Yigit >> <ferruh.yigit@amd.com>; andrew.rybchenko@oktetlabs.ru; >> dekelp@nvidia.com; psatheesh@marvell.com; NBU-Contact-Adrien Mazarguil >> (EXTERNAL) <adrien.mazarguil@6wind.com>; fengchengwen >> <fengchengwen@huawei.com>; Huisong Li <lihuisong@huawei.com>; >> Dengdui Huang <huangdengdui@huawei.com>; dev@dpdk.org; Ori Kam >> <orika@nvidia.com> >> Subject: Re: question about eth and vlan item in flow pattern >> >> Hi, >> >> Please see below. >> >> On Tue, 23 Apr 2024, Jie Hai wrote: >> >>> Hi, Ivan Malov, >>> Sorry for the late reply. >>> On 2024/4/10 21:19, Ivan Malov wrote: >>>> Hi Jie, >>>> >>>> Consider the following examples: >>>> 1) flow create 0 ingress pattern eth / ipv4 proto is 17 / udp / end \ >>>> actions queue index 1 / end >>>> 2) flow create 0 ingress pattern eth / ipv4 / udp / end \ >>>> actions queue index 1 / end >>>> >>>> Generally speaking, these two rules might be equivalent, with "proto is 17" >>>> in >>>> the first one probably being redundant (the very presence of "udp" >>>> item might stand for the same match criterion -- the protocol ID >>>> being 17). >>> I can understand that. >> Very well. >> >>>> >>>> And I'd be tempted to treat the "has_vlan" case similarly. Consider: >>>> 3) flow create 0 ingress pattern eth has_vlan is 1 / vlan / end \ >>>> actions queue index 1 / end >>>> 4) flow create 0 ingress pattern eth / vlan / end \ >>>> actions queue index 1 / end >>>> >>>> (rule (3) is similar to "rule-0" from your example) >>>> >>>> Rules (3) and (4) seem equivalent to me -- the "has_vlan is 1" bit >>>> might be redundant in flow (3) -- the presence of item "vlan" sort of >>>> means the same. >>> >>>> Rule (3) and (4) should probably match both single-tagged and >>>> double-tagged packets because, in both cases, the pattern does not >>>> clarify which protocol follows the outermost VLAN tag. If one needs >>>> to exclude double-tag match, they should clarify the rule in one of the >> possible ways, in example: >>>> >>>> - pattern eth / vlan has_more_vlan is 0 / end >>>> - pattern eth / vlan tpid is 0x0800 / end >>>> - pattern eth / vlan / ipv4 / end >>>> >>>> (the "tpid" goes to the "hdr.eth_proto" of "struct rte_flow_item_vlan"). >>>> >>> As mentioned above, `has_vlan is 1` and `vlan` are the same, which >>> means `vlan` stands for any-tagged vlan, Then, is the introduction of >>> `has_vlan` and `has_more_vlan` unnecessary? >> It's not clear why you believe it's unnecessary. Some vendors support boolean >> match on "is outer VLAN present" and "is inner VLAN present" >> in addition to exact match on TPID/TCI. It may be convenient to expose these >> match criteria as sub-fields in ETH and VLAN items. >> This should allow for faster parsing as one can drop item VLAN from pattern in >> case there's no intention to match on TPID/TCI. > > To expand the argument on convenience by providing an example, > `has_vlan` allows to construct a following logic: > > 1) flow create 0 group X ingress pattern eth has_vlan is 1 / end actions jump group Y / end > 2) flow create 0 group X ingress pattern eth has_vlan is 0 / end actions jump group Z / end > > 3) flow create 0 group Y ingress pattern eth / vlan vid is N / end actions /* actions for tagged traffic */ > 4) flow create 0 group Z ingress pattern eth / end actions /* actions for non-tagged traffic */ > > Traffic can be split between different groups - one group for tagged and another for non-tagged packets. > `has_vlan` gives more flexibility in the API. > >>> >>> There are drivers seeing `vlan` an one vlan layer and match 'eth/vlan/end' >>> with single-tagged packets, e.g.bnxt, hns3, etc. >>> I think this meaning makes it easier to distinguish the functions of the two. >>> >>> The `has_more_vlan is 1` is defined and used by some drivers, like mlx5. >>> While the `has_more_vlan is 0` is not defined. >> What do you mean by saying "not defined"? Not defined where? >> Having "has_more_vlan is 0" is perfectly legit, isn't it? >> >>> Here you give the meaning as `having no vlan after this vlan`. >>> Then, What should the follow rule mean? single-tagged or double tagged? >>> >>> - pattern eth / vlan tpid is 0x8100 has_more_vlan is 0 / end >> Item VLAN here is supposed to describe the header _immediately_ following >> the ETH one, isn't it? If so, the rule means single-tagged. Doesn't it? > > I also think this rule means single-tagged, but on the other hand I think it's also ill-defined. Thank you for noticing this. My bad. Indeed, this rule is just incorrect and shall be rejected by the driver -- that is because "tpid is 0x8100" means that the header following the outermost VLAN tag is yet another VLAN tag, whereas "has_more_vlan is 0" wants to match on the opposite, namely on the absence of the inner tag. So, in this rule, one match criterion contradicts another one. Parser should see through this. Thank you. > tpid field in VLAN item defines the inner packet type, > so this pattern should match the following packet: > > dmac=<any> > smac=<any> > ether_type=0x8100 // match single-tagged packet > pcp=<any> > vid=<any> > ether_type=0x8100 // from tpid VLAN item > > Which is an incorrect packet. > >> Thank you. >> >>> >>>> With regard to the question about VLAN ID match, "pattern eth / vlan >>>> vid is 10", as well as "pattern eth has_vlan is 1 / vlan vid is 10", >>>> should probably match only on the outermost tag ID, -- that is, not >>>> on the inner one and not on both. >>> I agree with it. >>>> That is because the "vid is 10" criterion relates to the specific >>>> header, as per the match item it sits in. If the user wants to match >>>> on the inner VLAN ID (say, 11), they should clarify specify it as follows: >>>> >>>> - pattern eth / vlan vid is 10 / vlan vid is 11 / end >>>> - pattern eth / vlan / vlan vid is 11 / end >>>> >>> >>>> Hopefully, the rest of DPDK vendor community can correct me in case I >>>> got that wrong. Should you have more questions, please feel free to ask >> such. >>>> >>>> Thank you. >>>> >>>> On Wed, 10 Apr 2024, Jie Hai wrote: >>>> >>>>> Hi, all, >>>>> >>>>> I have some questions about the sub-options for ``VLAN`` and ``ETH`` >> item. >>>>> >>>>> According to the documentation, ``has_vlan`` is sub-option of >>>>> ``ETH`` item and it means that the pattern contains at least one vlan. >>>>> The ``VLAN`` item is used to match tagged packets and have some >>>>> sub-options such as ``vid``, ``tci``, etc. >>>>> >>>>> If we combine them, what should the effect be? >>>>> For instance, >>>>> >>>>> rule-0: flow create 0 ingress pattern eth has_vlan is 1 / vlan / >>>>> end actions queue index 2 / end >>>>> rule-1: flow create 0 ingress pattern eth has_vlan is 1 / vlan vid >>>>> is 10 / end actions queue index 2 / end >>>>> >>>>> For rule-0, should it match single-tagged packets only or >>>>> multi-tagged only or both? >>>>> That is to say, which one will take effect, `has_vlan is 1` or >>>>> `vlan` or both? >>>>> >>>>> For rule-2, which packets should it match, with inner VLAN id 10, or >>>>> outer VLAN id 10, or both 10? >>>>> >>>>> The hns3 driver supports only the exact matching of VLAN numer. >>>>> And it is planned to adapt ``has_vlan`` and ``has_more_vlan`` to the >>>>> meaning of one VLAN for hns3 driver. Therefore, if the preceding >>>>> combinations are supported, we need to confirm the exact meanings. >>>>> >>>>> So, what are your views on the above question? >>>>> >>>>> >>>>> >>>>> >>>> . >>> > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: question about eth and vlan item in flow pattern 2024-04-24 21:46 ` Ivan Malov @ 2024-05-13 1:45 ` Jie Hai 0 siblings, 0 replies; 8+ messages in thread From: Jie Hai @ 2024-05-13 1:45 UTC (permalink / raw) To: Ivan Malov, Dariusz Sosnowski Cc: Yuying Zhang, Aman Singh, NBU-Contact-Thomas Monjalon (EXTERNAL), ferruh.yigit@amd.com >> Ferruh Yigit, andrew.rybchenko, dekelp, psatheesh, NBU-Contact-Adrien Mazarguil (EXTERNAL), fengchengwen, Huisong Li, Dengdui Huang, dev, Ori Kam On 2024/4/25 5:46, Ivan Malov wrote: > Hi, > > On Wed, 24 Apr 2024, Dariusz Sosnowski wrote: > >> >> To expand the argument on convenience by providing an example, >> `has_vlan` allows to construct a following logic: >> >> 1) flow create 0 group X ingress pattern eth has_vlan is 1 / end >> actions jump group Y / end >> 2) flow create 0 group X ingress pattern eth has_vlan is 0 / end >> actions jump group Z / end >> >> 3) flow create 0 group Y ingress pattern eth / vlan vid is N / end >> actions /* actions for tagged traffic */ >> 4) flow create 0 group Z ingress pattern eth / end actions /* actions >> for non-tagged traffic */ >> >> Traffic can be split between different groups - one group for tagged >> and another for non-tagged packets. >> `has_vlan` gives more flexibility in the API. >> >>>> >>>> There are drivers seeing `vlan` an one vlan layer and match >>>> 'eth/vlan/end' >>>> with single-tagged packets, e.g.bnxt, hns3, etc. >>>> I think this meaning makes it easier to distinguish the functions of >>>> the two. >>>> >>>> The `has_more_vlan is 1` is defined and used by some drivers, like >>>> mlx5. >>>> While the `has_more_vlan is 0` is not defined. >>> What do you mean by saying "not defined"? Not defined where? >>> Having "has_more_vlan is 0" is perfectly legit, isn't it? >>> >>>> Here you give the meaning as `having no vlan after this vlan`. >>>> Then, What should the follow rule mean? single-tagged or double tagged? >>>> >>>> - pattern eth / vlan tpid is 0x8100 has_more_vlan is 0 / end >>> Item VLAN here is supposed to describe the header _immediately_ >>> following >>> the ETH one, isn't it? If so, the rule means single-tagged. Doesn't it? >> >> I also think this rule means single-tagged, but on the other hand I >> think it's also ill-defined. > > Thank you for noticing this. My bad. Indeed, this rule is just incorrect > and shall be rejected by the driver -- that is because "tpid is 0x8100" > means that the header following the outermost VLAN tag is yet another > VLAN tag, whereas "has_more_vlan is 0" wants to match on the opposite, > namely on the absence of the inner tag. So, in this rule, one match > criterion contradicts another one. Parser should see through this. > > Thank you. Hi, all , I have some questions There are some other contradicted conditions: 1. eth has_vlan is 0 / vlan / end XXX 2. eth / vlan has_more_vlan is 0/ vlan / end XXX I think rule 1 and rule2 are both contradicted and should be rejected by drivers. 3. eth has_vlan is 1 / end XXX 4. eth / vlan has_more_vlan is 1 / end XXX 5. eth has_vlan is 1 / vlan has_more_vlan is 1 / end XXX 6. eth has_vlan is 1 / vlan has_more_vlan is 0 / end XXX Rule 3 should match tagged(>=1) and rule 4 should match multi-tagged(>=2) is definite. Since 'has_vlan is 1' is redundant with 'vlan'. 'has_vlan is 1' and 'vlan has_more_vlan is X', which one should be ignored, and which one should be effective. If 'has_vlan is 1' should be ignored， rule 5 is same as rule 4, and rule 6 should match single-tagged. If 'vlan has_more_vlan is X' should be ignored， rule 5 and rule 6 is the same and it seems literally unconscionable. What do you think about? Thanks you. > >> tpid field in VLAN item defines the inner packet type, >> so this pattern should match the following packet: >> >> dmac=<any> >> smac=<any> >> ether_type=0x8100 // match single-tagged packet >> pcp=<any> >> vid=<any> >> ether_type=0x8100 // from tpid VLAN item >> >> Which is an incorrect packet. >> >>> Thank you. >>> >>>> >>>>> With regard to the question about VLAN ID match, "pattern eth / vlan >>>>> vid is 10", as well as "pattern eth has_vlan is 1 / vlan vid is 10", >>>>> should probably match only on the outermost tag ID, -- that is, not >>>>> on the inner one and not on both. >>>> I agree with it. >>>>> That is because the "vid is 10" criterion relates to the specific >>>>> header, as per the match item it sits in. If the user wants to match >>>>> on the inner VLAN ID (say, 11), they should clarify specify it as >>>>> follows: >>>>> >>>>> - pattern eth / vlan vid is 10 / vlan vid is 11 / end >>>>> - pattern eth / vlan / vlan vid is 11 / end >>>>> >>>> >>>>> Hopefully, the rest of DPDK vendor community can correct me in case I >>>>> got that wrong. Should you have more questions, please feel free to >>>>> ask >>> such. >>>>> >>>>> Thank you. >>>>> >>>>> On Wed, 10 Apr 2024, Jie Hai wrote: >>>>> >>>>>> Hi, all, >>>>>> >>>>>> I have some questions about the sub-options for ``VLAN`` and ``ETH`` >>> item. >>>>>> >>>>>> According to the documentation, ``has_vlan`` is sub-option of >>>>>> ``ETH`` item and it means that the pattern contains at least one >>>>>> vlan. >>>>>> The ``VLAN`` item is used to match tagged packets and have some >>>>>> sub-options such as ``vid``, ``tci``, etc. >>>>>> >>>>>> If we combine them, what should the effect be? >>>>>> For instance, >>>>>> >>>>>> rule-0: flow create 0 ingress pattern eth has_vlan is 1 / vlan / >>>>>> end actions queue index 2 / end >>>>>> rule-1: flow create 0 ingress pattern eth has_vlan is 1 / vlan vid >>>>>> is 10 / end actions queue index 2 / end >>>>>> >>>>>> For rule-0, should it match single-tagged packets only or >>>>>> multi-tagged only or both? >>>>>> That is to say, which one will take effect, `has_vlan is 1` or >>>>>> `vlan` or both? >>>>>> >>>>>> For rule-2, which packets should it match, with inner VLAN id 10, or >>>>>> outer VLAN id 10, or both 10? >>>>>> >>>>>> The hns3 driver supports only the exact matching of VLAN numer. >>>>>> And it is planned to adapt ``has_vlan`` and ``has_more_vlan`` to the >>>>>> meaning of one VLAN for hns3 driver. Therefore, if the preceding >>>>>> combinations are supported, we need to confirm the exact meanings. >>>>>> >>>>>> So, what are your views on the above question? >>>>>> >>>>>> >>>>>> >>>>>> >>>>> . >>>> >> ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2024-05-13 1:45 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-04-10 11:37 question about eth and vlan item in flow pattern Jie Hai 2024-04-10 12:33 ` Thomas Monjalon 2024-04-10 13:19 ` Ivan Malov 2024-04-23 9:34 ` Jie Hai 2024-04-23 11:44 ` Ivan Malov 2024-04-24 20:21 ` Dariusz Sosnowski 2024-04-24 21:46 ` Ivan Malov 2024-05-13 1:45 ` Jie Hai
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).