From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f179.google.com (mail-qk0-f179.google.com [209.85.220.179]) by dpdk.org (Postfix) with ESMTP id 225972C49 for ; Thu, 9 Mar 2017 12:43:57 +0100 (CET) Received: by mail-qk0-f179.google.com with SMTP id 1so113746838qkl.3 for ; Thu, 09 Mar 2017 03:43:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yJhHvDkbdQCN/IgZHP67I6aIcL75lZnx1gv/MOR8PQg=; b=B+ZCn7IIopYn9fw7iPXjlatnPDU2Ep5gSRkAOcHooog+cOSGDnjQxKjngJuY/DDZ0U GdkhwKcf3YeHJbUD2RyAYKhKMl3zvns16GuujJ8hDMc75jNc/+edN28yOyr42Xdlg12l 64iOG0DPNB6WH8fqgyDUCp3OAfUahRHhiz9gp4pxVpgcgh6mVW9iiHEsQ/JMNc8dCp/H DWve2uhOe1Lu25wjpdgjAp9VA6WJNQCz2VzlNbphgeeo+PnsU8JZOa/tNWeRlRo0GRhI tSezJ6b3poV7MqI6G3r5aeCQWDAn3fcpukRPIMehhQ+lztQpcX4kASq9hO8Gff6G8dYU eywg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yJhHvDkbdQCN/IgZHP67I6aIcL75lZnx1gv/MOR8PQg=; b=egg2atZfEWdDewztiF2Q1VldidBn7iqiGPPQSyXOGja2krgqcbLVZpWBBpx48xX43i FuTQtXkVtCoIhKNsjeRAPUwsc73Fy6u+33BO5ik6eqG54tnfhia3ycZazu/tfvnQNK9r XayfdMRUV8fezTV0PXkyiy24RRs9MK5YpBUWbE+0CQlgPk2wCX+CCk+grNtTlaXDNt1r RsAt4hpb97d8y96Wgm+5qEu2xcpJJryTqrBAcTlWw/WNu2YF1aTDCRbwe0LiPAywT3b+ sQZgQjKDHnwarNOHkIgdPLDPX+oDU4fZp2N/t516pSRJ5X284cFidPnqIn3bYUJRmryb 6lwg== X-Gm-Message-State: AMke39nu8JBinvPJ0cvLQgPyBRWXfZx/zE1kpjhZ/aZGNSSHFIji9O4YFoSVWBHAT7gNkYJljdAZvIgZ5bdC0Q== X-Received: by 10.200.48.209 with SMTP id w17mr14747163qta.179.1489059836467; Thu, 09 Mar 2017 03:43:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.156.15 with HTTP; Thu, 9 Mar 2017 03:43:56 -0800 (PST) In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D891265275CF7A@IRSMSX108.ger.corp.intel.com> References: <3EB4FA525960D640B5BDFFD6A3D891265275CF7A@IRSMSX108.ger.corp.intel.com> From: Shyam Shrivastav Date: Thu, 9 Mar 2017 17:13:56 +0530 Message-ID: To: "Dumitrescu, Cristian" Cc: "dev@dpdk.org" , "Singh, Jasvinder" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] ip_pipeline firewall customization X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 11:43:57 -0000 Hi Cristian Please see my comments inline (in blue) > b) Make required changes in pipeline_firewall_msg_req_add_handler if > > portid is -1, that is table entry action to be .action = > > RTE_PIPELINE_ACTION_DROP. > > > > You don't really need to do this for implementing a drop action. You can > simply create a SINK output port (which basically drops all the packets > directed to it) and set this as the output port for all rules that drop > packet. > > See ip_pipeline/config/firewall.cfg as example. > Yes dropping of packets can be achieved by creating a sink port. However we need further processing to be done for a packet hitting a pass rule, and best way for this processing is f_action_hit table handler. In this routine we can distinguish between drop/pass actions as rte_pipeline_table_entry is passed to it, which also contains portid but no generic way to distinguish between normal or sink port. I think it would be value addition to allow this action in firewall pipeline, please let me know your thoughts. As for our project looks like we have to include this. > > > 2) I am registering a f_action_hit function for firewall table to perform > > certain translations if action is pass (RTE_PIPELINE_ACTION_PORT). > > What type of actions are you performing? If generic enough, it would be > interesting to add them to this pipeline, so I encourage you to contribute > with ideas and code patches. > > Probably it's not generic, involves vlan translation and mac swapping to inject the "passed" packets back to the router to travel to next hop. Router injects traffic for filtering to directly connected firewall port with vlan tag say A , firewall in turn injects pass traffic with different vlan tag say B back to the router which then does next hop processing. > > > > Is this a bug or am I missing something ? > > > > You can make sure no ARP packets are received by the firewall pipeline by > simply filtering all the ARP packets to a separate RXQ of the NIC port, > which can be further handled by a separate function. > > See ip_pipeline/config/network_layers.cfg as example: > [LINK0] > arp_q = 4 > There are two things here 1) ARP packets should not hit the ipv4 acl which looks like happening, have not worked on "why part" for now , need to look at the rte_table_acl_lookup->rte_acl_classify. 2) Yes we can filter ARP packets to a separate queue and to separate lcore at link level, but need to decide whether its worth it. We are planning to use ipv4 RSS (with 8 queues, lcores and processors) wherein all arp packets would get filtered to queue 0 by default and then dropped by ACL. Thanks and regards Shyam