Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

The link of port_config.ini is wrong in swss-schema.md #6

Closed
jeromesun14 opened this issue Mar 18, 2016 · 1 comment
Closed

The link of port_config.ini is wrong in swss-schema.md #6

jeromesun14 opened this issue Mar 18, 2016 · 1 comment

Comments

@jeromesun14
Copy link

swss-schema.md shows 'Stores information for physical switch ports managed by the switch chip. device_names are defined in port_config.ini. ', but the link of port_config.init ("https://github.com/stcheng/swss/blob/mock/portsyncd/port_config.ini", 404 not found) is wrong. I think it should be "https://github.com/Azure/sonic-swss/blob/master/portsyncd/port_config.ini".
@lguohan
Copy link
Contributor

lguohan commented Mar 18, 2016

fixed, thanks.

@lguohan lguohan closed this as completed Mar 18, 2016
@jipanyang jipanyang mentioned this issue Oct 13, 2017
Closed
lguohan pushed a commit that referenced this issue Feb 22, 2018
@lguohan
[portsorch]: Move PVID setting for port before adding it to LAG (#6)
86dd822 
Signed-off-by: Volodymyr Samotiy <volodymyrs@mellanox.com>
ishidawataru pushed a commit to ishidawataru/sonic-swss that referenced this issue Aug 29, 2018
@pavel-shirshov
Fix memory leak. Subscribe on key changes only when we need it (sonic…
4cf7a59 
…-net#6)

* Subsritbe to keyspace events when required. Otherwise memory leak
prsunny added a commit that referenced this issue Oct 10, 2018
@prsunny
VNET/VRF Changes (#632)
8d57ae0 
* VNET/VRF Changes  (#6)

* VRF changes

* Fixed an IPv6 address parsing issue

* Updated logs, removed intfmgr changes in favour of PR #635

* Updated VRF table name

* Addressed review comment, test fixes

* Remove extra semi-colon

* Route handling, review comments (#8)

* Vnet route table handling

* Addressed review comments

* Fix for interface routes, add debug logs
vasant17 added a commit to vasant17/sonic-swss that referenced this issue Nov 4, 2019
@vasant17 @zhenggen-xu
Added more DPB test cases and re-factored code (sonic-net#6)
b235183 
Code-cleanup
vasant17 added a commit to vasant17/sonic-swss that referenced this issue Nov 8, 2019
@vasant17 @zhenggen-xu
Added more DPB test cases and re-factored code (sonic-net#6)
bd63193 
Code-cleanup
@garigipati garigipati mentioned this issue May 22, 2020
Closed
@rajkumar38 rajkumar38 mentioned this issue Jul 29, 2020
Merged
dgsudharsan referenced this issue in dgsudharsan/sonic-swss Jun 15, 2021
@dgsudharsan
Changes #6 modifying vlan flood type set
c5766fe
@skbarista skbarista mentioned this issue Nov 29, 2022
Merged
@jcaiMR jcaiMR mentioned this issue Jan 30, 2023
Merged
oleksandrivantsiv referenced this issue in oleksandrivantsiv/sonic-swss Mar 1, 2023
@stcheng
make: adding --with-sai arg to select which SAI to compile with (#6)
8362b9f
oleksandrivantsiv referenced this issue in oleksandrivantsiv/sonic-swss Mar 1, 2023
@shruthi9 @lguohan
Dataplane telemetry support in SONiC (sonic-net#328)
c2c5e7c 
* initial barefoot checkin october 2017

* Revert "Merge branch 'master' of https://github.com/Azure/sonic-sairedis into rel_6_0"

This reverts commit c48a7a20de2fb9e615535481f8727029440413bc, reversing
changes made to aa5bf640db7b7fca245c1669eeb02198a50cb5c1.

* missed integration diffs

* Added new attr type support to sairedis. Also, some fixes for compilation issues

* Changes to add new DTel api support in sairedis

* Add new file to generate Dtel specific SAI stub API

* Missed adding a file in the last commit

* Fix ref point for SAI

* Updated SAI repo to point to dtel_exp

* Changes to handle new additions to DTel experimental SAI. Not compiled yet

* handle platform specific lins in different directory (@runtime)

* force order of library path to look for platform dir before lib dir

* Change SAI branch refpoint

* Update SAI submodule refpoint

* enable fast-boot for barefoot platforms

* Update ref point for SAI

* SONiC changes due to DTel experimental SAI changes

* allow Makefile to build for other platforms - restore it original for non-bfn platforms

* allow clean build

* Revert "allow clean build"

This reverts commit adfdb8642fe0b5dbb4e19d13871172a03a8c883b.

* Revert "allow Makefile to build for other platforms - restore it original for non-bfn platforms"

This reverts commit d6b0ca34fcf63d0b79c801cd95d7ee2fe58d21ac.

* makefile cleanup towards upstream

* Support for platforms based on Barefoot Networks' device (sonic-net#304)

* search for exact string - newer onie versions match multiple lines

* Will need to revert this

Should work without this change. Untested for now

* SONiC sairedis changes needed to work with SAIv1.3

* Fix SAI path in gitmodules and add a comment

* Remove sai thrift build hack

* enable fast-boot for barefoot platforms

* enable fast-boot for barefoot platforms

* Add missing sai rpc hdr file path for bfn

* Update SAI ref points

* Multi p4 profile support for bfn sde (#5)

* Remove code duplicated in merge

* Keep fn in same order as azure master (sonic-net#8)

* Address review comment

* Link just bfn sai lib and shorten linking command by removing other libraries linked at compile time (#6)

* Link only bfn sai lib

* all unresolved symbols resolved at runtime

* Preload some bfn libraries on syncd startup

* Build fix

* also remove commented code

* Convert tabs to spaces

* Fix alignment

* Address upstream comment

* BFN: link with just sai library for saisdkdump

* Address review comments
lukasstockner pushed a commit to genesiscloud/sonic-swss that referenced this issue Apr 2, 2023
@jleveque
More changes for compatibility with both Python 2 and 3 (sonic-net#6)
9adb75f
qiluo-msft pushed a commit that referenced this issue Aug 7, 2023
@vivekrnv
[ASAN] Fix Indirect Mem Leaks in Orchagent (#2869)
23cb2e5 
**What I did**

Fix the Mem Leak by moving the raw pointers in type_maps to use smart pointers

**Why I did it**

```
Indirect leak of 83776 byte(s) in 476 object(s) allocated from:
    #0 0x7f0a2a414647 in operator new(unsigned long) ../../../../src/libsanitizer/asan/asan_new_delete.cpp:99
    #1 0x5555590cc923 in __gnu_cxx::new_allocator, std::allocator > const, referenced_object> > >::allocate(unsigned long, void const*) /usr/include/c++/10/ext/new_allocator.h:115
    #2 0x5555590cc923 in std::allocator_traits, std::allocator > const, referenced_object> > > >::allocate(std::allocator, std::allocator > const, referenced_object> > >&, unsigned long) /usr/include/c++/10/bits/alloc_traits.h:460
    #3 0x5555590cc923 in std::_Rb_tree, std::allocator >, std::pair, std::allocator > const, referenced_object>, std::_Select1st, std::allocator > const, referenced_object> >, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >::_M_get_node() /usr/include/c++/10/bits/stl_tree.h:584
    #4 0x5555590cc923 in std::_Rb_tree_node, std::allocator > const, referenced_object> >* std::_Rb_tree, std::allocator >, std::pair, std::allocator > const, referenced_object>, std::_Select1st, std::allocator > const, referenced_object> >, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >::_M_create_node, std::allocator > const&>, std::tuple<> >(std::piecewise_construct_t const&, std::tuple, std::allocator > const&>&&, std::tuple<>&&) /usr/include/c++/10/bits/stl_tree.h:634
    #5 0x5555590cc923 in std::_Rb_tree_iterator, std::allocator > const, referenced_object> > std::_Rb_tree, std::allocator >, std::pair, std::allocator > const, referenced_object>, std::_Select1st, std::allocator > const, referenced_object> >, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >::_M_emplace_hint_unique, std::allocator > const&>, std::tuple<> >(std::_Rb_tree_const_iterator, std::allocator > const, referenced_object> >, std::piecewise_construct_t const&, std::tuple, std::allocator > const&>&&, std::tuple<>&&) /usr/include/c++/10/bits/stl_tree.h:2461
    #6 0x5555590e8757 in std::map, std::allocator >, referenced_object, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >::operator[](std::__cxx11::basic_string, std::allocator > const&) /usr/include/c++/10/bits/stl_map.h:501
    #7 0x5555590d48b0 in Orch::setObjectReference(std::map, std::allocator >, std::map, std::allocator >, referenced_object, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >*, std::less, std::allocator > >, std::allocator, std::allocator > const, std::map, std::allocator >, referenced_object, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >*> > >&, std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&) orchagent/orch.cpp:450
    #8 0x5555594ff66b in QosOrch::handleQueueTable(Consumer&, std::tuple, std::allocator >, std::__cxx11::basic_string, std::allocator >, std::vector, std::allocator >, std::__cxx11::basic_string, std::allocator > >, std::allocator, std::allocator >, std::__cxx11::basic_string, std::allocator > > > > >&) orchagent/qosorch.cpp:1763
    #9 0x5555594edbd6 in QosOrch::doTask(Consumer&) orchagent/qosorch.cpp:2179
    #10 0x5555590c8743 in Consumer::drain() orchagent/orch.cpp:241
    #11 0x5555590c8743 in Consumer::drain() orchagent/orch.cpp:238
    #12 0x5555590c8743 in Consumer::execute() orchagent/orch.cpp:235
    #13 0x555559090dad in OrchDaemon::start() orchagent/orchdaemon.cpp:755
    #14 0x555558e9be25 in main orchagent/main.cpp:766
    #15 0x7f0a299b6d09 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x23d09)
```
StormLiangMS pushed a commit that referenced this issue Aug 14, 2023
@vivekrnv @StormLiangMS
[ASAN] Fix Indirect Mem Leaks in Orchagent (#2869)
63b08b5 
**What I did**

Fix the Mem Leak by moving the raw pointers in type_maps to use smart pointers

**Why I did it**

```
Indirect leak of 83776 byte(s) in 476 object(s) allocated from:
    #0 0x7f0a2a414647 in operator new(unsigned long) ../../../../src/libsanitizer/asan/asan_new_delete.cpp:99
    #1 0x5555590cc923 in __gnu_cxx::new_allocator, std::allocator > const, referenced_object> > >::allocate(unsigned long, void const*) /usr/include/c++/10/ext/new_allocator.h:115
    #2 0x5555590cc923 in std::allocator_traits, std::allocator > const, referenced_object> > > >::allocate(std::allocator, std::allocator > const, referenced_object> > >&, unsigned long) /usr/include/c++/10/bits/alloc_traits.h:460
    #3 0x5555590cc923 in std::_Rb_tree, std::allocator >, std::pair, std::allocator > const, referenced_object>, std::_Select1st, std::allocator > const, referenced_object> >, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >::_M_get_node() /usr/include/c++/10/bits/stl_tree.h:584
    #4 0x5555590cc923 in std::_Rb_tree_node, std::allocator > const, referenced_object> >* std::_Rb_tree, std::allocator >, std::pair, std::allocator > const, referenced_object>, std::_Select1st, std::allocator > const, referenced_object> >, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >::_M_create_node, std::allocator > const&>, std::tuple<> >(std::piecewise_construct_t const&, std::tuple, std::allocator > const&>&&, std::tuple<>&&) /usr/include/c++/10/bits/stl_tree.h:634
    #5 0x5555590cc923 in std::_Rb_tree_iterator, std::allocator > const, referenced_object> > std::_Rb_tree, std::allocator >, std::pair, std::allocator > const, referenced_object>, std::_Select1st, std::allocator > const, referenced_object> >, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >::_M_emplace_hint_unique, std::allocator > const&>, std::tuple<> >(std::_Rb_tree_const_iterator, std::allocator > const, referenced_object> >, std::piecewise_construct_t const&, std::tuple, std::allocator > const&>&&, std::tuple<>&&) /usr/include/c++/10/bits/stl_tree.h:2461
    #6 0x5555590e8757 in std::map, std::allocator >, referenced_object, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >::operator[](std::__cxx11::basic_string, std::allocator > const&) /usr/include/c++/10/bits/stl_map.h:501
    #7 0x5555590d48b0 in Orch::setObjectReference(std::map, std::allocator >, std::map, std::allocator >, referenced_object, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >*, std::less, std::allocator > >, std::allocator, std::allocator > const, std::map, std::allocator >, referenced_object, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >*> > >&, std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&) orchagent/orch.cpp:450
    #8 0x5555594ff66b in QosOrch::handleQueueTable(Consumer&, std::tuple, std::allocator >, std::__cxx11::basic_string, std::allocator >, std::vector, std::allocator >, std::__cxx11::basic_string, std::allocator > >, std::allocator, std::allocator >, std::__cxx11::basic_string, std::allocator > > > > >&) orchagent/qosorch.cpp:1763
    #9 0x5555594edbd6 in QosOrch::doTask(Consumer&) orchagent/qosorch.cpp:2179
    #10 0x5555590c8743 in Consumer::drain() orchagent/orch.cpp:241
    #11 0x5555590c8743 in Consumer::drain() orchagent/orch.cpp:238
    #12 0x5555590c8743 in Consumer::execute() orchagent/orch.cpp:235
    #13 0x555559090dad in OrchDaemon::start() orchagent/orchdaemon.cpp:755
    #14 0x555558e9be25 in main orchagent/main.cpp:766
    #15 0x7f0a299b6d09 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x23d09)
```
StormLiangMS pushed a commit that referenced this issue Aug 14, 2023
@vivekrnv @StormLiangMS
[ASAN] Fix Indirect Mem Leaks in Orchagent (#2869)
bc9bde9 
**What I did**

Fix the Mem Leak by moving the raw pointers in type_maps to use smart pointers

**Why I did it**

```
Indirect leak of 83776 byte(s) in 476 object(s) allocated from:
    #0 0x7f0a2a414647 in operator new(unsigned long) ../../../../src/libsanitizer/asan/asan_new_delete.cpp:99
    #1 0x5555590cc923 in __gnu_cxx::new_allocator, std::allocator > const, referenced_object> > >::allocate(unsigned long, void const*) /usr/include/c++/10/ext/new_allocator.h:115
    #2 0x5555590cc923 in std::allocator_traits, std::allocator > const, referenced_object> > > >::allocate(std::allocator, std::allocator > const, referenced_object> > >&, unsigned long) /usr/include/c++/10/bits/alloc_traits.h:460
    #3 0x5555590cc923 in std::_Rb_tree, std::allocator >, std::pair, std::allocator > const, referenced_object>, std::_Select1st, std::allocator > const, referenced_object> >, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >::_M_get_node() /usr/include/c++/10/bits/stl_tree.h:584
    #4 0x5555590cc923 in std::_Rb_tree_node, std::allocator > const, referenced_object> >* std::_Rb_tree, std::allocator >, std::pair, std::allocator > const, referenced_object>, std::_Select1st, std::allocator > const, referenced_object> >, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >::_M_create_node, std::allocator > const&>, std::tuple<> >(std::piecewise_construct_t const&, std::tuple, std::allocator > const&>&&, std::tuple<>&&) /usr/include/c++/10/bits/stl_tree.h:634
    #5 0x5555590cc923 in std::_Rb_tree_iterator, std::allocator > const, referenced_object> > std::_Rb_tree, std::allocator >, std::pair, std::allocator > const, referenced_object>, std::_Select1st, std::allocator > const, referenced_object> >, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >::_M_emplace_hint_unique, std::allocator > const&>, std::tuple<> >(std::_Rb_tree_const_iterator, std::allocator > const, referenced_object> >, std::piecewise_construct_t const&, std::tuple, std::allocator > const&>&&, std::tuple<>&&) /usr/include/c++/10/bits/stl_tree.h:2461
    #6 0x5555590e8757 in std::map, std::allocator >, referenced_object, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >::operator[](std::__cxx11::basic_string, std::allocator > const&) /usr/include/c++/10/bits/stl_map.h:501
    #7 0x5555590d48b0 in Orch::setObjectReference(std::map, std::allocator >, std::map, std::allocator >, referenced_object, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >*, std::less, std::allocator > >, std::allocator, std::allocator > const, std::map, std::allocator >, referenced_object, std::less, std::allocator > >, std::allocator, std::allocator > const, referenced_object> > >*> > >&, std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&) orchagent/orch.cpp:450
    #8 0x5555594ff66b in QosOrch::handleQueueTable(Consumer&, std::tuple, std::allocator >, std::__cxx11::basic_string, std::allocator >, std::vector, std::allocator >, std::__cxx11::basic_string, std::allocator > >, std::allocator, std::allocator >, std::__cxx11::basic_string, std::allocator > > > > >&) orchagent/qosorch.cpp:1763
    #9 0x5555594edbd6 in QosOrch::doTask(Consumer&) orchagent/qosorch.cpp:2179
    #10 0x5555590c8743 in Consumer::drain() orchagent/orch.cpp:241
    #11 0x5555590c8743 in Consumer::drain() orchagent/orch.cpp:238
    #12 0x5555590c8743 in Consumer::execute() orchagent/orch.cpp:235
    #13 0x555559090dad in OrchDaemon::start() orchagent/orchdaemon.cpp:755
    #14 0x555558e9be25 in main orchagent/main.cpp:766
    #15 0x7f0a299b6d09 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x23d09)
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@lguohan @jeromesun14