summaryrefslogtreecommitdiffstats
path: root/src/vnet/ethernet
AgeCommit message (Expand)AuthorFilesLines
2019-12-17ip: Protocol Independent IP NeighborsNeale Ranns8-3208/+212
2019-12-10api: multiple connections per processDave Barach1-1/+1
2019-11-27misc: add address sanitizer heap instrumentationBenoît Ganne1-0/+1
2019-11-26ethernet: all dmac checks include secondary addrsMatthew Smith1-19/+106
2019-11-26fib: Table ReplaceNeale Ranns2-37/+0
2019-11-25vlib: autogenerate <node> before <last-in-arc> constraintsDave Barach1-1/+1
2019-11-20classify: per-interface rx/tx pcap capture filtersDave Barach1-2/+12
2019-10-29ethernet: VNET API to create sub-interfacesNeale Ranns2-0/+45
2019-10-03ethernet: fix dmac filter coverity warningMatthew Smith1-1/+1
2019-10-02ethernet: dmac filter checks secondary mac addrsMatthew G Smith3-34/+186
2019-09-26misc: add vnet classify filter set supportDave Barach1-4/+2
2019-09-24vlib: add flag to explicitelly mark nodes which can init per-node packet traceDamjan Marion1-0/+1
2019-09-23misc: unify pcap rx / tx / drop traceDave Barach1-8/+8
2019-09-20misc: classifier-based packet trace filterDave Barach1-1/+15
2019-09-16api: autogenerate api trace print/endianOle Troan2-1/+28
2019-09-04ethernet: move dmac filtering to inline functionMatthew Smith1-56/+63
2019-09-03ethernet: fix dmac check avx2 loop conditionMatthew Smith1-1/+1
2019-08-20api: Cleanup APIs interface.apiJakub Grajciar1-0/+1
2019-08-06ethernet: change to mark the CFI bit in the L2 header.Prashant Maheshwari1-3/+3
2019-08-02ethernet: fix ARP feature arc definitionDave Barach1-2/+9
2019-08-01ethernet: Fix node ordering on ARP feautre ARCNeale Ranns1-2/+13
2019-07-15interface: fix issue that pcap rx/tx trace not available when there are worke...Wei CHEN1-4/+5
2019-07-10ip: fix show ip neigh vector read overflowBenoît Ganne1-19/+6
2019-07-05ethernet: ARP disabled nodeNeale Ranns1-15/+106
2019-07-03misc: fix coverity warningsDave Barach1-0/+5
2019-07-02ip: check all fib src for a connected dst entryBenoît Ganne1-25/+53
2019-06-07p2p ethernet: update p2p_ethernet.api with explicit types.Ole Troan1-5/+8
2019-06-03ARP: add feature arcNeale Ranns2-142/+476
2019-05-28Punt: socket register for exception dispatched/punted packets based on reasonNeale Ranns1-0/+1
2019-05-16init / exit function orderingDave Barach4-30/+28
2019-04-24ethernet_input_inline: leverage vlib_get_buffersZhiyong Yang1-17/+14
2019-04-10ethernet: fix packet tracingBenoît Ganne1-1/+1
2019-04-08fixing typosJim Thompson1-1/+1
2019-03-28Add RDMA ibverb driver pluginBenoît Ganne1-0/+11
2019-03-28Typos. A bunch of typos I've been collecting.Paul Vinciguerra1-5/+5
2019-03-21BVI InterfaceNeale Ranns2-2/+2
2019-03-15Revert "API: Cleanup APIs interface.api"Ole Trøan1-1/+0
2019-03-15API: Cleanup APIs interface.apiJakub Grajciar1-0/+1
2019-03-13deprecate VLIB_NODE_FUNCTION_MULTIARCHFilip Tehlar1-8/+5
2019-03-05L2: ARP term - learn but don't send response to GARPsNeale Ranns1-0/+3
2019-02-26Move pcap rx/tx trace code out of the dpdk pluginDave Barach1-17/+42
2019-02-22Callback functions must have the correct signatureNeale Ranns1-1/+3
2019-02-07Fix parsing overflow in unformat_mac_address_t()Benoît Ganne1-3/+3
2019-02-02Deprecate old mutliarch code, phase 1Damjan Marion1-3/+0
2019-01-30Use IP and MAC API types for neighborsNeale Ranns8-228/+265
2019-01-23IP route local and connectedNeale Ranns1-1/+5
2018-12-22ethernet-input tagged packets optimizationsDamjan Marion1-269/+474
2018-12-18PAPI: Add MACAddress object wrapper for vl_api_mac_address_tOle Troan3-16/+7
2018-11-26Add a feature arc consistency checkDave Barach1-0/+1
2018-11-26Remove unused argument from eth_identify_subint(...)Damjan Marion2-4/+2
, all of the VPP API client signatures that are supported by the CSIT tests in that branch are contained in separate directories under the .../csit/resources/api/vpp directory. The CSIT VPP API client signature directory structure is the same as the one published in /usr/share/vpp/api as generated by vppapigen. The granularity of the CSIT VPP API client signature support will initially be on a per VPP API JSON file. In the future, a per VPP api message level of granularity may be added. If CSIT is capable of supporting more than one version of a VPP API JSON file, then a new CSIT VPP api client signature directory will be created containing all of the supported VPP API JSON files. Typically this will be identical to the previous version with the exception of the VPP API JSON files which have been changed in the VPP patch which triggered the VPP API FLAG day algorithm. See https://gerrit.fd.io/r/19027 for the baseline implementation. **VPP API CHANGES FILE INCLUDED in VPP PACKAGE** The VPP build system shall add a file in the /usr/share/vpp/api directory of the vpp package which is the same directory in which the api JSON files are published. This file will include the list of VPP api files which were included in the patch to be verified. See https://gerrit.fd.io/r/19479 for the baseline implementation. **CSIT VPP API CHANGE DETECTION TEST** The set of VPP api signatures which are supported by the CSIT tests in a given CSIT branch shall be stored in .../csit/resources/api/vpp which mirrors the same directory structure as the API signature directory generated by vppapigen (e.g. /usr/share/api/vpp/core & /usr/share/api/vpp/plugins). The test compares the VPP patch's API signature directory with each of the CSIT VPP API signabture directory and determine the following state: - No Change - Changed - Rebase or Merge Parent VPP Patch [0] [0] The Rebase or Merge Parent VPP Patch result occurs when there is no valid API signature found in .../csit/resources/api/vpp AND there are no VPP API changes included in the patch. This could be the result of a patch whose parent does not include the API changes merged in another VPP patch and supported by the new CSIT oper branch. This case would be resolved by rebasing the patch to HEAD. The other possibility is that the patch is a descendent of a patch with an incompatible API change that has not been merged yet. This case is resolved by completing the API Flag Day algorithm on the parent patch such that the latest CSIT oper branch supports the API in the parent. This importance of the detection of this state is to provide direct feedback to the VPP patch author about how to resolve the issue in a timely manner. Any condition other than "No Change" shall cause an email to be sent to the VPP patch submitter. If the condition is "Changed" then vpp-api-dev@lists.fd.io shall also be copied on the notification email. **RUN CSIT VERIFY JOB AGAINST A SPECIFIC VPP PATCH IN GERRIT REVIEW BRANCH** This is the "Patch-On-Patch" methodology documented in [TBD]? **VPP API FLAG DAY SCENARIOS** In the beginning, let's assume there is a single VPP API Client signature directory in the current oper branch called vpp-api-client.sig.1 which contains core/vpe.api.json and plugin/acl.api.json which are supported by the CSIT tests. **VPP PATCH CONTAINS INCOMPATIBLE API CHANGES** Next, a VPP developer modifies vpe.api with a whole set of new type definitions. When the patch is submitted to gerrit.fd.io, the "CSIT VPP API CHANGE DETECTION TEST" detects the changed api file and votes Verified -1. Once CSIT has been updated to support the new type definitions and verified against the VPP patch, vpp-api-client.sig.1/core/vpe.api.json is replaced with the vpe.api.json file from the patch. The CSIT changes are committed into CSIT master and a new oper branch is created. The VPP patch is then rechecked and merged into VPP master as soon as practicable. All existing VPP patches and any new patches not including the VPP api change patch will fail verification with a "Rebase or Merge Parent" notification upon recheck or initial submission to gerrit. Rebasing is then required in order to pass verification of the new api changes. **VPP PATCH CONTAINS BACKWARDS COMPATIBLE CHANGES** The next day, a VPP developer finds a need to add a new attribute to an api message in vpe.api with a default value defined. This is a backwards compatible change for CSIT. Since the "CSIT VPP API CHANGE DETECTION TEST" only works on a per api file level of granularity, the change is flagged with Verified -1. However, in this case, the CSIT developer can resolve the verify failure by adding a second VPP API client signature directory, vpp-api-client.sig.2 which is a copy of vpp-api-client.sig.1 with the vpe.api.json file updated with the contents of the copy from the VPP patch. After the CSIT changes are merged and a new CSIT oper branch is created, the VPP patch will pass verification upon recheck. All other patches will continue to pass verification upon recheck or initial submission to gerrit by matching the signature in vpp-api-client.sig.1 -- life is good. **CSIT REMOVES SUPPORT FOR A VPP API VERSION** Since it is not desirable to maintain a bazillion CSIT VPP API client signatures, after a reasonable period of time (let's say a week), a CSIT developer deletes vpp-api-client.sig.1 and renames vpp-api-client.sig.2 to vpp-api-client.sig.1, merges to CSIT master, and creates a new oper branch. At this point, VPP patches that do not contain the new vpe.api file will fail verification upon recheck or initial submission to gerrit with a "Rebase or Merge Parent" notification and will require rebasing to pass verification. **CSIT ADDS SUPPORT FOR A NEW FEATURE API PRIOR TO VPP** A VPP developer has lots of ideas and decides to add a new plugin and api which supports the "Super-Duper Feature" to VPP in a new plugin called the "Super-Duper Plugin" and associated super_duper.api VPP binary APi message definition file. Being a thoughtful and helpful developer, the VPP developer notifies the CSIT team providing them with the super_duper.api.json file. A CSIT developer quickly produces the Super-Duper Feature CSIT test suite and updates the VPP API Client signature with vpe-api-client.sig.1/plugin/super_duper.api.json. In the meantime, the VPP developer pushes the Super-Duper VPP patch which fails the CSIT VPP API CHANGE DETECTION TEST. Both developers then work together to verify both CSIT and the VPP patch. The CSIT developer then merges the CSIT code into master and creates a new oper branch. Our VPP developer is very pleased when the VPP patch containing the Super-Duper Plugin verifies upon recheck. All other VPP patches without api file changes continue to pass the CSIT VPP API CHANGE DETECTION TEST before and after the Super-Duper VPP patch is merged. **VPP PATCH CONTAINS A NEW FEATURE API BEFORE CSIT SUPPORT** Now let's assume that the VPP developer was having a bad day and forgot to notify the CSIT team about the new Super-Duper Plugin. Upon pushing the VPP patch to gerrit, the VPP developer is pleased that there is no nastygram email from the CSIT VPP API CHANGE DETECTION TEST. All VPP patches without api file changes continue to pass the CSIT VPP API CHANGE DETECTION TEST. Eventually a Super-Duper Plugin test suite is added to CSIT along with vpe-api-client.sig.1/plugin/super_duper.api.json and release in a new CSIT oper branch. All VPP patches that are do not contain api changes and are verified via recheck or initial submission, continue to pass the CSIT VPP API CHANGE DETECTION TEST.