search for: check_failed

On Sun, Mar 26, 2023 at 05:41:06PM +0200, Hans Schultz wrote: > On Mon, Mar 20, 2023 at 10:44, Ido Schimmel <idosch at nvidia.com> wrote: > >> + $MZ $swp1 -c 1 -p 128 -t udp "sp=54321,dp=12345" \ > >> + -a $mac -b `mac_get $h2` -A 192.0.2.1 -B 192.0.2.2 -q > >> + tc_check_packets "dev $swp2 egress" 1 1 > >> + check_fail $?

On Mon, Mar 20, 2023 at 10:44, Ido Schimmel <idosch at nvidia.com> wrote: >> + $MZ $swp1 -c 1 -p 128 -t udp "sp=54321,dp=12345" \ >> + -a $mac -b `mac_get $h2` -A 192.0.2.1 -B 192.0.2.2 -q >> + tc_check_packets "dev $swp2 egress" 1 1 >> + check_fail $? "Dynamic FDB entry did not age out" > > Shouldn't this be check_err()? After

On Tue, Mar 28, 2023 at 19:40, Ido Schimmel <idosch at nvidia.com> wrote: > On Sun, Mar 26, 2023 at 05:41:06PM +0200, Hans Schultz wrote: >> On Mon, Mar 20, 2023 at 10:44, Ido Schimmel <idosch at nvidia.com> wrote: >> >> + $MZ $swp1 -c 1 -p 128 -t udp "sp=54321,dp=12345" \ >> >> + -a $mac -b `mac_get $h2` -A 192.0.2.1 -B 192.0.2.2 -q >>

On Sat, Mar 18, 2023 at 03:10:10PM +0100, Hans J. Schultz wrote: > +# Test of dynamic FDB entries. > +locked_port_dyn_fdb() > +{ > + local mac=00:01:02:03:04:05 > + local ageing_time > + > + RET=0 > + ageing_time=$(bridge_ageing_time_get br0) > + tc qdisc add dev $swp2 clsact > + ip link set dev br0 type bridge ageing_time $LOW_AGEING_TIME > + bridge link set dev

On Tue, Mar 28, 2023 at 19:40, Ido Schimmel <idosch at nvidia.com> wrote: > On Sun, Mar 26, 2023 at 05:41:06PM +0200, Hans Schultz wrote: >> On Mon, Mar 20, 2023 at 10:44, Ido Schimmel <idosch at nvidia.com> wrote: >> >> + $MZ $swp1 -c 1 -p 128 -t udp "sp=54321,dp=12345" \ >> >> + -a $mac -b `mac_get $h2` -A 192.0.2.1 -B 192.0.2.2 -q >>

Test FDB ageing of user entry created by bridge fdb replace ADDR dev <DEV> master dynamic Use LOW_AGEING_TIME variable in forwarding.config to set a low ageing time. Beware, DSA might not accept the ageing time you want. Check the age_time_coeff value for your driver. Signed-off-by: Hans J. Schultz <netdev at kapio-technology.com> --- .../net/forwarding/bridge_locked_port.sh |

On Tue, Mar 28, 2023 at 09:30:08PM +0200, Hans Schultz wrote: > On Tue, Mar 28, 2023 at 19:40, Ido Schimmel <idosch at nvidia.com> wrote: > > On Sun, Mar 26, 2023 at 05:41:06PM +0200, Hans Schultz wrote: > >> On Mon, Mar 20, 2023 at 10:44, Ido Schimmel <idosch at nvidia.com> wrote: > >> >> + $MZ $swp1 -c 1 -p 128 -t udp "sp=54321,dp=12345" \

...last); } - cache = btrfs_find_block_group(root, cache, last, data, 0); + if (!full_scan) + cache = btrfs_find_block_group(root, cache, last, data, 0); *cache_ret = cache; cache_miss = 0; goto again; @@ -955,8 +957,8 @@ static int find_free_extent(struct btrfs path = btrfs_alloc_path(); check_failed: - search_start = find_search_start(root, &block_group, - search_start, total_needed, data); + search_start = find_search_start(root, &block_group, search_start, + total_needed, data, full_scan); cached_start = search_start; btrfs_init_path(path);

We had this discussion a few months ago and it petered out, and it’s recently been revived in the context of upgrading the CMake version specifically for libc++ (at which point people suggested upgrading the CMake version used by all of LLVM), so let’s try to move this forward. Our current required minimum version is CMake 3.4.3, which was released on January 25th 2016. It’s interesting to note

On Thu, Mar 26, 2020 at 11:48 PM Nikita Popov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Thu, Mar 26, 2020 at 9:07 PM Shoaib Meenai via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> We had this discussion a few months ago and it petered out, and it’s recently been revived in the context of upgrading the CMake version specifically for libc++ (at which

Assuming this is a one-time version bump, this seems reasonable to me. Perhaps this goes without saying, but the warning for point 1 should only happen if you don’t have CMake >= 3.13.4 installed. It sounded to me from your original message that you have an urgent need to upgrade to 3.8. Were you planning on going ahead with that right away? From: llvm-dev <llvm-dev-bounces at

I’m in favor of all this. Thanks for volunteering! I’m happy to help out in whatever way. Some things it might be worth figuring out for future upgrades: * If we want to limit ourselves to CMake versions supported by LTS releases of distros, which distros should we consider, and how far back should we go (i.e. is it just the latest LTS or the last two LTS versions)? * For platforms like Ubuntu

Ubuntu 20.04 LTS will be released soon, and I believe it’ll have CMake 3.16.3, so that increases the LTS lower bound significantly. I strongly disagree with the sentiment that the build system already works so there’s no urgent need to improve it. I believe we should treat the build system like code, and the same ideas around refactoring apply. Our build system is a huge thorny mess; there’s tons

> On Apr 2, 2020, at 10:19, Louis Dionne via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Okay, so we've had some discussion on this thread, and although some people (including me) would like a more aggressive policy, I believe the following will not get any objection (based on the thread). On April 23rd 2020, Ubuntu 20.04 LTS will ship with CMake 3.16.x. This will make the

'Supported' means that it comes from the packages available from the distribution that can be seen via this page. https://packages.ubuntu.com/ These packages have been processed by the Ubuntu community to obtain a reliability expectation that would not apply, for example, to a PPA. The difference between installing or building Clang and LLVM from original sources as against

Every additional dependency that we force the user to manually install (either by building from source, or adding some new PPA to their ubuntu system), raises the barrier to entry that much higher. Just because we may require the user to manually install some newer compiler on their system doesn’t mean that we should also require them to install some newer CMake than what’s on their system.

> You're saying "doesn’t mean that we should" while I've been saying in this situation that "we can", there is quite a difference here I believe. Technically “we can” do anything we want. We can always require that the project be built with the current release candidate of CMake. That doesn’t mean that we should. From: Mehdi AMINI <joker.eph at gmail.com>

I think it does make a difference how many things we ask new developers to do to get up and running - because we've asked them to do one thing doesn't mean it's low-cost to ask them to do another thing. On Tue, Apr 7, 2020 at 11:20 AM Mehdi AMINI via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Tue, Apr 7, 2020 at 9:16 AM Chris Tetreault <ctetreau at

> On Apr 7, 2020, at 22:16, Mehdi AMINI via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On Tue, Apr 7, 2020 at 11:27 AM David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote: > I think it does make a difference how many things we ask new developers to do to get up and running - because we've asked them to do one thing